Instalar cualquier versión de un programa en sistemas *nix, ¿posible o un camino de mártires?

Simplemente échale un ojo a snap, flatpack o appimage, que es por lo que estás preguntando.


En general los repositorios normales solo se mantiene la últimas versiones por el simple hecho de «comodidad y seguridad». En el 99.999% los casos, los usuarios preferirán la última versión del software, tanto por incluir novedades (aunque no las usen tampoco les molesta) como corrección de bug y temas de seguridad. Generalmente las versiones nuevas deberían haber pasado un filtro previo y asegurar que mejora la actual por el propio mantenedor del paquete. Lógicamente se puede escapar algún problema, pero suele ser ocasiones muy reducidas.


Si todo el «follón» simplemente te viene por Audacity, creo recordar que la mayoría de las distribuciones desactivan cualquier rastro de telemetría o la dejan como opcional antes de subir el paquete a sus repos.

‎MiguelAngel LV escribió:Simplemente échale un ojo a snap, flatpack o appimage, que es por lo que estás preguntando.

Que es de lo que hablabais en un hilo recientemente, pero uno de los problemas que tiene es que eso sólo es válido para GNU/Linux, pero no para *BSD.

Pero, además, lo que veo (no hay nada como preguntar para acabar buscando por tu cuenta la respuesta), es que todo depende del desarrollador. Si el desarrollador de un software sin mantenimiento hoy no hizo un paquete de este tipo en su día, adiós. Puede que con los programas más comunes tenga un empaquetado de este tipo, pero con software que no conoce ni el tato (y baste que sea ese el que te vendría de perlas), supongo que ni de broma, así que volvemos al dilema, ¿es posible, o es un camino de piedras?

Dejando eso de lado por un momento, vámonos al otro lado del tendido, a *nix *BSD.

Veo que están los jails, que no sé si acabo de entender si podrían servir, pero que los jails, en esencia, son máquinas virtuales con versiones de los sistemas *BSD completas (vamos, un despropósito de espacio en disco). Es incoherente tener varias versiones de un sistema *BSD para poder ejecutar software viejo (que no es por la edad, sino por las dichosas dependencias dinámicas sobre librerías no actualizadas o disponibles).

No sé si pudriere serviría, pero me parece que no.

Total que, volviendo al punto muerto donde me he quedado antes, acabo encontrando desde los manuales de *BSD que está chroot, que está disponible en todos los sistemas *nix. ¿Es esto lo que hacen, en esencia, los sistemas de paquetería anteriores?

Pero, ¿estoy equivocado o es otro despropósito similar a las jails de *BSD en cuanto a espacio?

O sea, para hacer funcionar un software viejo en un chroot, habría que hacer una copia del sistema actual en otro directorio pero con las librerías en versiones que necesite ese programa y "sólo eso", suponiendo que los kernel son realmente retrocompatibles.

¿Es así?

Al final, si de virtualizar o duplicar un sistema se trata, me parece más plausible lo que dije de Wine y/o virtualizar un Windows :S e intentar seguir usando Win32/64. Al menos no tendrías que hacer tanta virtualización por cada software y tendrías "algo de garantía" de usar software a largo plazo en el tiempo.



¿Estas son las opciones? ¿no podría usar un software X que sirva a mis necesidades si nadie lo hace compatible con las últimas versiones? ¿realmente no hay manera?

Que no estoy diciendo que voy a usar software viejo de primeras, pero quiero atenerme a las consecuencias, quiero entender el entorno en el que me tendré que mover y no quedarme con los brazos cruzados y apechugando si un día, porque sí, un software que me es de utilidad deja de estar disponible para las últimas versiones de los sistemas.

Porque Audacity tiene la suerte de que hay gente que haya creado forks y no habría problemas, pero habrá software que no corra esa misma suerte.

Y ojo, en Windows, a día de hoy, me pasa, pero al revés, de tener que virtualizar un Windows moderno para ejecutar cierto software, pero, bueno, es un sistema virtual y ya, no varios, como parecen plantear las jails de *BSD.

En resumen, que quiero saber a qué atenerme. A mis posibilidades.

‎MiguelAngel LV escribió:Si todo el «follón» simplemente te viene por Audacity, creo recordar que la mayoría de las distribuciones desactivan cualquier rastro de telemetría o la dejan como opcional antes de subir el paquete a sus repos.

No, el "follón" no viene por Audacity. Audacity sólo es un ejemplo claro del problema y que me vino al pelo para abrir este hilo y preguntar para aprender

Y lo que quiero tener claro es si es tan complejo instalar y correr software "viejo", pero útil al usuario, en un sistema *nix. En definitiva, si hay tantas piedras en el camino para correr el software que cada usuario elija.


Seré yo, pero yo no soy de estar actualizado, empezando por el hardware, siguiendo por los programas que me son útiles y acabando por el sistema.

En sistemas *nix, desde luego, lo tengo claro, pero me va a costar una barbaridad hacerme a la idea de que o uso la última versión del sistema, o adiós al software porque, o desparece el repositorio o los ports/paquetes para las versiones antiguas (antiguas, pero por meses) y sin software, mal vamos, pero lo de no poder usar versiones de software anteriores, pufff, peor aún.

Si ya de por sí parece super complejo correr software que no está actualizado para la última versión de un sistema, ya no hablemos de usar una versión de sistema de hace... yo qué sé, ¿5 años? y además software "viejo".

‎MiguelAngel LV escribió:En el 99.999% los casos, los usuarios preferirán la última versión del software, tanto por incluir novedades (aunque no las usen tampoco les molesta)

Diferentes formas de consumir software. Si un software engorda y no me deja adelgazarlo, no me gusta quedarme con la diabetes porque "¡tiene un sombrero nuevo!".

Será que soy de software minimalista.

‎MiguelAngel LV escribió:como corrección de bug

Sí, y no.

Un ejemplo propio en Windows.

Recientemente me percaté de un bug no crítico (más que bug, fallo) en un software que utilizo que tiene ya sus 20 años.

El programa tuvo versiones posteriores (aún existe su web), pero nunca actualicé por lo dicho, si funciona y cumple, y las mejoras tampoco lo eran para mí, no necesito otra versión.

Bueno, pues actualicé porque hubo una versión que lo corregía y ya que había versiones más nuevas, pues, a por la última.

¿Y qué pasó?, que se cargó una funcionalidad. La funcionalidad bien podría ser entendida como bug o como feature, todo sea dicho. Para mí era una feature y muy útil.

¿Qué tuve que hacer?, pues volver a una versión anterior. Esa es la posibilidad que quiero tener o quiero saber hasta qué punto, o con qué opciones, puedo obtener en sistemas *nix.

A veces es mejor que un software tenga un fallo no crítico que actualizar y quedarse con la peor versión.

¿Es todo el software así? No, pero ocurre y más de lo que parece.

‎MiguelAngel LV escribió:temas de seguridad.

Nunca acabaré de entender esa obsesión con que la última versión es la más segura.

No voy a argumentar porque al final tendríamos un flamewar y una desviación absoluta del tema pero no estoy de acuerdo con la afirmación "última versión === seguridad".

‎MiguelAngel LV escribió:Generalmente las versiones nuevas deberían haber pasado un filtro previo y asegurar que mejora la actual por el propio mantenedor del paquete.

Lo que decía antes. Es que las mejoras para unos pueden no serlo para otros. Yo pertenezco a ese 0.001% que no prefieren ni necesitan las novedades de la última versión, salvo casos específicos.


Perdón por este kilométrico mensaje, otra vez, pero es la única forma de explicar, preguntar y que se me entienda.

@caja roja no puedes coger las fuentes de una versión concreta, compilarte esa versión y ponerla a funcionar? En Debian posiblemente puedas encontrar los .deb de una versión concreta y instalarlo en tu equipo.
No tienes porque ir siempre a la última; en Debian tienes por ejemplo, distintas ramas estable, testing, inestable para evitar eso que dices

No sé si puedo, porque no lo sé. Ni tampoco cómo (para empezar, no sé programar ni compilar, (hacer javascript no creo que se le pueda llamar programar)). Quiero aprender si se puede hacer (no, compilar, no, el tema del hilo) y cómo porque lo veo muy negro para poder correr los programas que el usuario quiera.

Eso que comentas, tengo algo leído, e igual es porque tengo un "cacao maravillao" en la cabeza por las *BSD, pero siempre he leído que dan problemas por el tema de las dependencias.

O sea, si supongamos que hay compilar X software (de lo que no tengo ni pajolera) pero luego necesitas una versión de compilador determinada para convertirlo en binario o una librería específica para ejecutarlo, te encuentras con que no puedes instalar esa versión del compilador porque colisionaría con dependencias de otros programas y tampoco podrías instalar otras librerías para ejecutarlo porque pasaría lo mismo y al final no podrías ejecutar uno u otro programa según las dependencias.

Por eso parece que existen los temas estos de los sistemas de paqueterías de snap, flatpack y appimage que, en parte, cuando se puede, solucionan estos problemas. Pero veo que tiene el problema que comentaba antes. El principal, que no está para todo programa viviente. Estos sistemas parecen relativamente nuevos y sólo para GNU/Linux.

Y los sistemas altenativos, que si chroots, que si jaulas, que si virtualizaciones.... pues meten otro problema. Estoy en hardware viejo y no es que me sobre tampoco el espacio porque un día decida que ese programa viejo es lo que quiero ejecutar y necesito X espacio extra sólo por ese programa.

Y me gustaría aclarar esto a ver si es tan complejo.

Luego, para añadir más miga, resulta que anoche, leyendo, chroot sólo es para comandos de texto, pero no para aquellos que usen ventanas :S Para eso hay xchroot, pero no está para *BSD (lástima).

Y hablas de Debian y tal vez se podría, ¿sin restricciones como las que digo de dependencias de librerías?, pero, ¿y el resto de distribuciones GNU/Linux? ¿También es tan simple? ¿no existen estos problemas de dependencias que digo?

¿Lo puede hacer alguien que no sepa programar?

¿Y con las *BSD?

Pregunto también de los *BSD y por eso hablo de *nix siempre que puedo en el hilo, porque casi me llama más los *BSD (aunque por aquí pocos usuarios he visto hablando de *BSD).

Pero, por ejemplo, hace poco, porque de todo esto voy mirando poco a poco información aquí y allí, miré y resulta que Seamonkey, ojo SEAMONKEY, no cualquier programa al pelo, no se podría ejecutar en sistemas *BSD porque no está actualizada la dependencia con librerías python (creo que era).

Corrección: veo en freshports que no era por la librería, era porque estaba "obsoleto" y tenía "agujeros de seguridad". En fin, no voy a comentar nada del tema de seguridad, por lo dicho en el otro mensaje, pero es un argumento muy triste.

Me quede con el culo torcido. Tenían un cacao en un hilo de los foros de FreeBSD que es para no echar gota.

Luego, como digo, voy mirando cosas de aquí y de allí, y estaba buscando un gestor de ventanas ligero. Encontré uno y lo mismo. Que no se soporta porque es que no está compilado para X librería de no sé qué lenguaje. Estoy mirando en el historial para deciros cuál era por no doy con él. No sé, he mirado ya un número tan ingente de gestores de ventanas que después de ese fracaso ya no sé cuál utilizaré y otra vez a buscar.

Corrección: Este si era por la librería, no Seamonkey.


Y ahí es donde llega realmente todo el "cacao maravillao" que tengo montado en la cabeza. Los sistemas *nix permiten mucha libertad, cierto, pero también estoy viendo que eso es si te limitas a lo último de lo último, o sea, si eres un "usuario cómodo" (o un dummy, sin ánimo de ofender) como decía "MiguelAngel LV". Como te salgas del carril, como quieras un software especial, y tampoco tanto, como Seamonkey, "agárrate que hay curvas", que si no se puede compilar, que si lo compilas puede generar conflictos, que si tienes que crear jaulas, que si tienes que virtualizar que si... habrá algo más, seguro que hay algo más, pero ojalá que no.

En Windows está claro que no existe este dilema. Incluso con programas nuevos, de ayer mismo, si no están compilados para las últimas versiones de Windows (muchas veces creo que por equivocación porque no necesitan para nada funciones de Windows modernas (por ejemplo los que compilan para el último .NET para utilidades básicas, hasta calculadoras)), se pueden incluso ejecutar en versiones de Windows viejas.

En *nix estoy viendo que esto es muy, muy, muy, muy complicado. Yo creo que, hasta siendo programador, es casi imposible.

Quiero saber que no es así, quiero hasta que me convenzáis que esto no es así. Quiero ver la luz, que lo veo todo muy negro.

Si en Windows ya cansa virtualizar, no quiero vivir el mismo martirio en *nix, aunque me libre de Windows como sistema base.

Y pregunto esto en elotrolado.net porque me moriría yendo a cada foro de cada distribución a preguntar, encima en inglés, y con reglas estrictas de publicación de "no digas esto no digas aquello que te baneamos" y aquí hay usuarios de todos los sinsabores de *nix y, con suerte, algo más abiertos

Es muy facil y tienes varias opciones: (te voy a poner el ejemplo de Debian, que es lo que conozco)

[*]Puedes descargarte un .deb desde los repos de una versión anterior de Debian e instalarlo manualmente (me refiero a darle doble click y que te lo instale un programa) en un Debian (o derivados) y ver que pasa. Lo más probable es que te funcione.
[*] Puedes añadir los repos de otra versión de Debian e instalar desde ese repo. Se llama "pinning"
[*]Puedes instalar una versión anterior de Debian (en MV o a capón) y usar las versiones de entonces.
[*]Obviamente, si no te funciona o vale nada de lo anterior, puedes instalarlo manualmente compilando desde la fuente (suele consistir en leerte el readme del código y seguir sus instrucciones) y buscando las dependencias.

Una vez instalado lo puedes marcar con apt como "no actualizable" y no te va a actualizar ese paquete en las actualizaciones periódicas (si es que las haces)

¿Pero lo confirmas?

¿Confirmamos que esto en el entorno Debian sí es posible entre tu opinión y la de newton?

Insistes en el puedes, puedes, puedes... probar, pero, ¿sabes qué?, que si abro este hilo es para no estar media vida probando distribuciones *nix y ver si esta sí o esta no. Insisto, no tengo un hardware moderno, no tengo demasiado espacio, estoy en un sistema de 32-bit y eso, además, me limita a virtualizar sistemas *nix 32-bit y hay bastantes distribuciones que he ido mirando que encajaban con mis perspectivas que se cambiaron a sólo 64-bit o cualquier otra razón que me han puesto piedras en el camino. O sea, tiempo perdido.

Y doy gracias de que acabo de ver que Debian ¡está en 32 bits!. Juraría que se habían pasado a sólo "64-bit". O lo confundo con lo de systemd.

Ah, no, mira era Arch, y acabo de ver que la comunidad ha creado una versión de 32-bit (¡milagro!).

Pero ahora seguro que me pondré a leer sobre tal o cual y en X tiempo adiós a los 32-bit. Que sí, que tiene que llegar el día, y el procesador que tengo es x86_64 pero para probar necesito lo que necesito. Matarme en instalar un Windows 64 que rompe mi flujo de trabajo para probar un *nix 64 es la cuadratura del círculo.

Que podría aprovechar para preguntar y no lo he hecho, pero ¿qué hay de las versiones de los sistemas? ¿Puedo quedarme en *nix -X versiones y vivir con tranquilidad? Está ligado, precisamente, al tema de instalar versiones de los programas. ¿Qué pasaría si no me puedo permitir actualizar el hardware y me quedo X versiones por detrás? ¿podría seguir instalando software en esa versión?

Por ejemplo esto ha pasado con FreeBSD 13, que ha retirado, con lógica, mucha lógica, soporte a determinados controladores de red. Casualidad que uno de esos controladores servía para el hardware de red virtualizado que usa MS Virtual PC, lo cual me obligaría a probar FreeBSD anclado a la versión 12, que en un año y medio se queda sin soporte o re-aprender VirtualBox (que no me gusta nada porque no me permite el control sobre el disco que permite MS Virtual PC).

En Windows no hay problema en usar un sistema sin soporte (podría seguir instalando el software que quisiera (quien le de soporte, claro), podría hacer lo que sigo haciendo), pero, ¿en sistemas *nix, que está todo tan ligado a estar siempre actualizado, que está tan ligado a los repositorios?

De cualquier manera, cada distribución *nix es un paradigma diferente y tengo ya la cabeza de manuales (manuales que pueden servir para un sistema pero no para otro), de distribuciones, de todo, hasta decir basta y, con sinceridad, me matáis cuando ahora me decís que Debian podría hacer lo que digo, porque he invertido tanto tiempo (porque no dedico todo mi tiempo) en familiarizarme con el paradigma FreeBSD...

GNU/Linux no tiene un sistema base per se, sino que depende de cada distribución, cosa que no ocurre con los *BSD, lo que genera un paradigma con diferentes herramientas, diferente sistema base, etc.

Por eso no arranco con *nix, pero os agradezco que me confirméis estas cosas. Mi cabeza ya no da más de sí.

El tema de saber si puedo instalar la versión del software que yo quiera sólo es la punta del iceberg. Yo busco un sistema configurable desde abajo, sin extras que no quiero y no necesito, es decir, básico, base, y para mi eso implica que ocupe poco, si es posible, que el disco no es de dedicación exclusiva al sistema (he leído burradas de los requerimientos de los entornos de escritorio necesitando varias veces lo que el sistema básico). Sé que eso en Arch se puede conseguir, pero, ¿y en Debian?, ¿puedo? (tengo poco leído de Debian). Pero antes me gustaría saber si en Arch, por ejemplo, también se puede instalar cualquier versión del software, si no, acabo como con FreeBSD, que vas aprendiendo el paradigma, vas diciendo, "oye, mira esto se hace así, asá, para luego stop, ¿no puedo hacer esto?", ahora a aprender otro y así hasta el infinito.

Yo entiendo que algunos tengáis recursos y tiempos infinitos para probar esta distribución, luego aquella, luego acullá. Admiro que podáis saltar de Arch a Debian, de Debian a Manjaro, de Manjaro a Gentoo, de Gentoo a Slack; luego que si sistemas de arranque (systemd, init, rc, lo que sea), diferentes shells, diferentes sistemas de archivos, etc... pero a mí no me da para tanto. No quiero estar re-aprendiendo el paradigma constantemente.

Pero no se trata tanto de re-aprender sino de conocer bien el sistema que usas. Un sistema, no todos, y quedarte con él pudiendo administrarlo de forma adecuada al conocerlo bien.

No existe el sistema perfecto, pero al menos un sistema con el que te sientas a gusto. Creo que se entiende.

Por eso necesito saber y confirmar los paradigmas de los sistemas *nix respecto a cosas tan """"simples""" como si se puede instalar el software que el usuario quiera en vez de probar. Sí, claro que podría probar, si tuviera dos vidas, o tres, o más de un equipo. Necesito vuestras experiencias previas.

Necesito de vuestra experiencia para poder elegir.

Y luego ya está esto

‎Esog Enaug escribió:[*]Obviamente, si no te funciona o vale nada de lo anterior, puedes instalarlo manualmente compilando desde la fuente (suele consistir en leerte el readme del código y seguir sus instrucciones) y buscando las dependencias.

Puffffffffffffffffffffffffffffff. Lo veréis muy fácil. Yo no. He leído más de una vez los archivos Makefile y no entiendo ni papa. Y digo makefile porque no recuerdo haber visto un Readme dando instrucciones, y si lo he visto, seguro que no entendí ni papas.

Ahora, te tomo la palabra con que se puede, y si hay que aprender algo de programación, no quedará otra, pero sin tener que perder el tiempo antes probando una distribución que no lo permite.

En fin, perdonadme por estos mensajes tan largos, en los me pego más rato del que parece para escribir y que se me entienda

Otra alternativa puede ser tirar de dockers...

@caja roja

Te confirmo que funciona exactamente como digo. Uso Debian Testing con un par de paquetes provenientes de la versión 10 estable y están marcados como "no actualizables", paquetes 386 (para poder usar wine) y paquetes instalados de forma manual (sin repo). Y todo funciona como debería, excepto algún juego de windows.

Debian destaca por su robustez y, en versión estable, paquetes un poco desactualizados pero súper probados.

Sobre lo de hacer el sistema mínimo, sobre la base de Debian netinstall (y supongo que pasa lo mismo con Arch e incluso Ubuntu server) puedes montar un sistema tan ligero como quieras, instalando los escritorios pelados o gestores de ventanas. Puedes usar otras distros creadas para ser MUY ligeras, pero por experiencia te digo que no se les puede pedir demasiado.

‎MiguelAngel LV escribió:Otra alternativa puede ser tirar de dockers...

He tenido que mirar la Wikipedia porque me sonaba de algo, no sé si de leerlo aquí, pero eso también peca del abuso del espacio porque es casi como montar una máquina virtual. Dice que usa menos recursos, pero me suena que sería un despropósito como los jails o los chroot.

De todas formas, me quedo con ello para al menos saber que existe.

Supongo que será similar a NixOS (dí a parar anoche ahí, no sé cómo). Me pareció un concepto de sistema interesante. Casi por descontado que abusando del espacio y no para usuarios finales, pero interesante al fin y al cabo.

‎Esog Enaug escribió:@caja roja
Te confirmo que funciona exactamente como digo. Uso Debian Testing con un par de paquetes provenientes de la versión 10 estable y están marcados como "no actualizables", paquetes 386 (para poder usar wine) y paquetes instalados de forma manual (sin repo). Y todo funciona como debería, excepto algún juego de windows.

Me gusta esto que me cuentas.

‎Esog Enaug escribió:Sobre lo de hacer el sistema mínimo, sobre la base de Debian netinstall (y supongo que pasa lo mismo con Arch e incluso Ubuntu server) puedes montar un sistema tan ligero como quieras, instalando los escritorios pelados o gestores de ventanas. Puedes usar otras distros creadas para ser MUY ligeras, pero por experiencia te digo que no se les puede pedir demasiado.

El problema de las distribuciones ligeras es el de todas las distribuciones y es que, aunque ligeras, dependes de lo que le quiere meter cada montador. Ya no es que vengan peladas es que vienen hoy con un programa para administrar un componente del sistema, y mañana con otro. Que vengan peladas casi es lo de menos.

Estuve probando Antix y al final, eso es lo que pasa. Lo que tienes hoy, no lo tienes mañana. Que es lo mismo, pero no lo mismo. El problema del paradigma y tener que re-aprender otro programa.

Así que eso me llevó a lo que voy buscando, es decir, un sistema base estable, conocer el sistema, el sistema real, es decir, el sistema de texto y de ahí tirar hacia arriba poniendo o quitando lo que a mí me parezca útil, no lo que le parezca al montador de la distribución de turno. ¿De qué me sirve acostumbrarme al programa X para administrar Y, si luego van a venir y me lo van a quitar? (Y en esto entra en juego también el hecho de poder instalar un programa no mantenido pero funcional, o sea, una versión vieja) Conociendo el sistema, como si el programa se llama pepito. Y sé que para esto, si tiras por un sistema gráfico, están los entornos de escritorio, supuestamente estables en programas para la administración y fáciles, pero es que no puedo con ellos, con su concepto. No puedo aceptar que necesiten una bestialidad de espacio por mucho que faciliten la vida. Veo más sensato un sistema Frankestein light que un sistema armónico desbocado.

Pero lo que decía antes, y por eso me empecé a enfocar en *BSD, en GNU/Linux no hay un sistema base común y por eso me parece más complejo decidir quedarse con una distribución GNU/LInux y no puedes pegarte media vida probando.

Encima, aunque parezca al revés, yo he empezado por el tejado, es decir, por conocer el sistema, cuando debería haber conocido qué permite el sistema y luego meterme en el sistema.

Vamos, que tenía que haber preguntado antes como estoy preguntando ahora. Pero, claro, estas limitaciones nos las ves hasta que empiezas a meterte en el funcionamiento del sistema.

Por cierto, aunque este hilo sea un tostón (de largo), se aceptan nuevas datos y opiniones Si en otras distribuciones la posibilidad de instalar cualquier versión de un programa da menos problemas o lo que sea.

@caja roja Siento ser pesado, pero tú eres un usuario perfecto para Debian estable: sus inconvenientes son ventajas para tí,

caja roja escribió:

MiguelAngel LV escribió:Otra alternativa puede ser tirar de dockers...

Dice que usa menos recursos, pero me suena que sería un despropósito como los jails o los chroot.

De todas formas, me quedo con ello para al menos saber que existe.

Los dockers se usan de forma muy habitual al montar servicios en servidores, la bajada de rendimiento es simplemente imperceptible.

Usando de base distribuciones «ultra ligeras», el espacio que ocupa es ridículo. Por ejemplo, las basadas en alpine parten de los 5MB más lo que pueda necesitar el software que utilices. Un postgresql instalado así, por ejemplo, son unos 300mbs.

‎Esog Enaug escribió:@caja roja Siento ser pesado, pero tú eres un usuario perfecto para Debian estable: sus inconvenientes son ventajas para tí,

Tú sé todo lo pesado que necesites

Pero explícate

¿Sus inconvenientes son ventajas para mí?, ¿qué inconvenientes?, ¿perfecto por qué?


@"‎MiguelAngel LV"

Lo que veo es que Dockers tampoco sería lo que quiero de un sistema.

Una de las cosas que me hizo frenar con *BSD (es una cosa que llevo ya tiempo rumiando, como decía al principio, pero no conseguía encontrar una respuesta clara) era el concepto de las jails para correr software viejo porque el proceso queda aislado del sistema (de ahí el término jaula) y los Dockers tampoco se diferencian mucho en este tema. Se crean procesos, pero están aislados del resto. Y, si no, lo tengo mal entendido, pero de todas formas suponían un despropósito de espacio en disco. Una forma rebuscada de ejecutar programas ports/paquetes no mantenidos.

Por ponerlo de una forma clara y que se pueda entender más gráficamente todo este tema (el tema del hilo).

Supongamos que me gusta un visor de imágenes que dejó de desarrollarse hace 13 años (hablo de forma absolutamente hipotética). Que en sí eso no es el problema (puede tener un soporte algo deficiente a algunos cambios en los formatos de imagen, pero ya), sino que por las filosofías *nix (siempre actualizado) el programa se queda sin mantenedor y por tanto no es posible utilizarlo en las últimas versiones de los sistemas *nix porque no están actualizadas las dependencias del programa hacia estás últimas versiones de sistemas *nix. Sea por las razones que sea (en *BSD la seguridad, con razón por su orientación base: los servidores).

Entiendo que usando jails, chroots, dockers o lo que sea, al estar aislado el proceso, no sería tan fácil como abrir la imagen y que me abra el proceso instalado bajo estos sistemas para correr software sin problemas de dependencias.

Y no lo he pensado al escribirlo, pero en realidad se asemeja mucho a mi realidad actual en Windows. Yo uso todavía, agarraos, ACDsee 3.x (tendrá ya en torno a 22 años o así). Sí, y funciona. A lo más que he tenido que hacer por mi parte, de forma manual, es actualizar los plugins del programa (que es el soporte a los formatos de imagen) y tal vez añadir alguna dll de alguna dependencia que pudiera tener algún plugin y que no existiera en alguna versión determinada de Windows. Pero vaya, los formatos de imagen tampoco es que hayan cambiado demasiado. Hasta le añadí soporte webp usando los plugins de una versión más reciente...

Es decir, es un programa que da igual la versión de Windows y da igual lo viejo que sea. Va a funcionar como el primer día. Eso es lo que busco poder hacer en *nix. No, no es lo que busco, es la limitación que no quisiera tener.

Que da igual si decido quedarme con una versión vieja... porque sí, porque me da más comodidad, mejor flujo de trabajo, por lo que sea; poder ejecutarla, da igual si el sistema *nix es la última "release" de este año o es la versión objetivo para la que fue realizado ese programa, pongamos, 15 años, por poner un ejemplo bruto, versión, yo qué sé, 1.0.5.8 (número inventado) de una distribución.

Por eso pregunto si es posible o es un camino de piedras.

No es que cuando me ponga a utilizar un sistema *nix de forma habitual vaya a buscar intencionadamente software viejo (de hecho, al principio tiraré sí o sí de Wine o un Windows virtualizado porque es casi inevitable (bueno, para jugar, seguro)), pero puede darse el caso de no encontrar lo que busco en los repositorios pero que sí exista X programa en una web que hizo alguien, que ya ha desaparecido, o que lo abandonó, o que hizo el programa por libre sin añadirlo a repositorios.

Y como todo software viejo en un sistema nuevo, o un software nuevo en un sistema viejo, no tiene por qué funcionar, pero al menos no estar limitado de base a no poder ejecutar software viejo. Y quien dice viejo dice 5 años, tampoco hace falta que sean 25 años.

Aunque encontré algunos gestores de ventanas viejunos que me gustaban y ya tenían sus años

Otra parrafada y no tenía intención, que es Domingo.

caja roja escribió:

Esog Enaug escribió:@caja roja Siento ser pesado, pero tú eres un usuario perfecto para Debian estable: sus inconvenientes son ventajas para tí,

Tú sé todo lo pesado que necesites

Pero explícate

¿Sus inconvenientes son ventajas para mí?, ¿qué inconvenientes?, ¿perfecto por qué?

Los inconvenientes que tiene la gente con debian stable, es que usa software "anticuado" muchas gente quiere tener siempre las últimas novedades debian stable no las tiene, ya que congela paquetería bastante antigua para que sea estable como una roca con todo más que probado.

(de hecho, al principio tiraré sí o sí de Wine o un Windows virtualizado porque es casi inevitable (bueno, para jugar, seguro))

Que da igual si decido quedarme con una versión vieja... porque sí, porque me da más comodidad, mejor flujo de trabajo, por lo que sea; poder ejecutarla

En caso de que tu flujo de trabjo sea necesario tanto windows, no veo utilidad en ponerte ni bsd ni unix.

Para mi gusto el tema de cambiarte de windows a -> *nix, bsd, te "obliga" a tí cambiar tu flujo de trabajo, ya que como dices dependes de muchos programas windows.

Si fuera solo por tema de juegos, lo más sencillo y casi 100% compatible es tener dualboot, dejas windows solo para juegos, y vas cambiando tu flujo de trabajo en *nix, bsd, con los programas que dispone cada uno.

Por ejemplo en mi caso, en el día a día en el trabajo, uso navegador, editor visual studio code,Keepass, php, mysql, git y la terminal. Mi flujo de trabajo es 95% igual cuando arranco en este caso Windows 11 a cuando arranco Manjaro Linux, ¿por qué no es 100% igual? porque para parte del trabajo que tengo que hacer 1 vez cada x semanas, necesito un programa que solo está en windows y con wine no tira nada bien, quitando eso podría hacer 100% lo mismo en uno que en otro.

En el ordenador que tengo en el salón con la tv, mi flujo de trabajo en el son solo videojuegos, así que uso lo que mejor va para el, que es windows, no me obligo a usar linux en el porque se que voy a estar más tiempo ajustando cosas para los juegos que tengo que jugando. Si en tu caso no puedes modificar/adaptar tu flujo de trabajo a algo 100% cercano al uso en *nix, bsd, sinceramente no lo uses.

Un saludo

PD: Con esto quiero decir que cualquier SO está para usarlo y te debes ajustar a los programas y necesidades que tienes, muchas veces la gente usa microsoft word y dice que ese es su flujo de trabajo, pero realmente lo que usa del programa lo puede hacer con Libreoffice o con Google Docs, incluso con wordpad.
PD2: ¿Por qué uso Manajaro? Porque me gusta tener las últimas novedades, ¿Por qué no uso entonces Arch? Pues porque me es más cómodo que por defecto las intalación sea automática como la de Manjaro.
PD3: En el trabajo hemos migrado todos los servidores a Ubuntu 20.04 ¿Porqué? Pues porque teníamos Centos 6 sin soporte, el paso al 7 y al 8 no era factible, porque centos 8 es un poco la betatester de RedHat y para tener algo estable y con bastante comunidad hemos mirado lo más común actualmente.

@"‎luciferfran"

Supongo que no me he explicado suficientemente.

Yo cuando hablo de flujo de trabajo no estoy diciendo que el sistema deba comportarse igual en Windows o *nix. Si no entendemos la pregunta del hilo como tal. Yo no la estoy planteando así.

El tema va por no poder ejecutar los programas que yo quiera (versiones, de lo que va este hilo) porque haya distribuciones *nix que tengan un esquema que no den pie a la ejecución de versiones "obsoletas" de programas.

Estoy preguntando para evaluar los posibilidades de elegir una distribución que tenga un sistema de libertad de ejecución de software similar a Windows. No, borra eso de tu mente, no similar a Windows, que debería tener espero que tenga cualquier sistema, cada uno con su repertorio de programas disponibles, por supuesto, sea, por ejemplo, Photoshop en Windows o Gimp en *nix.

Si existe, si es posible. Con Debian estáis diciendo que se podría.

Si no existe, pues me aguantaré, pero también tendré que evaluar si me merece la pena quedarme con un Windows que no me agrada (y me está exigiendo en hardware, y no me refiero al TPM, me refiero en recursos en general; pero no sólo es por un tema de hardware) o adaptarme a un sistema radicalmente opuesto (en lo que al tema del hilo se trata, no por sus diferencias).

Lo que, a mi parecer, tú estás planteando, es el debate entre el fin y el medio del sistema (el debate que tenéis tienen en el hilo de si GNU/Linux puede ser un sistema de uso del día a día). Para mí el sistema, sea Windows o *nix es el medio para poder hacer cosas, no es el fin en sí mismo como pueda darse en algunas distribuciones que es "o así o de ninguna manera".

Es decir, para algunos, el fin, porque para mí por lo menos es un fin, es estar siempre actualizado y a la última, y lo respeto, aunque no lo comparto. En *nix estaba empezando a ver que es así, sí o sí (y de ahí el hilo, para aclararlo, para aclararme y poder tomar una decisión), pero es que ese no es mi fin.

Mi fin, en cambio, es tener libertad para ejecutar lo que necesite, pero, como he dicho antes, con las posibilidades de software de cada sistema.

No es que *nix sea nuevo para mí, pero hasta que no me he puesto ya serio con el tema no he visto esta limitación. Lo que para mí es una limitación.

De todas formas, no presumas que dependo de programas de Windows porque quiera usar Wine o virtualizar un Windows. Te sorprenderías de la cantidad de software de código abierto que uso y que está disponible en las dos plataformas.

Argumentar eso es como argumentar que por usar el subsistema de GNU/Linux en Windows es depender de los programas GNU/Linux y entonces lo que se debería utilizar es GNU/Linux.

Desde hace tiempo, cada vez que me surgía algo, me ponía a buscar si tendría esa alternativa en *nix. Qué programa podría suplirlo o cómo hacerlo. Esto no es un viaje con la venda en los ojos de me voy a poner un *nix sí o sí. Caiga quien caiga. Es ver si puedo, si me compensa, si... la pregunta del asunto del hilo y todo lo que he ido diciendo a lo largo del tema.

Lo que dices de la plataforma de juegos. Toda la vida he cacharreado para hacer funcionar un juego (es lo que tiene no estar a la última en hardware, que siempre hay que toquetear aquí, allí y allá ) así que es no es un problema. Pero considerar a Windows como única plataforma de juegos, también es considerar a Windows como un fin en si mismo.

Tú lo que necesitas es una consola ;P (permíteme este guiño cómplice y no te enfades).

Por eso creo que nadie está en contra de que *nix gane en soporte de juegos. Porque el sistema debe ser un medio, no un fin. Cada uno con su propia idiosincrasia, pero un medio, y que cada uno debe elegir si le gusta uno u otro (que, por cierto, estoy sacando a Mac de la ecuación aunque no deje de ser casi un *BSD). O, ¿qué pasa, que si quiero jugar tengo que usar Windows sí o sí? Ojalá algún día esto sea cosa del pasado.

Pero ya no juego tanto y lo que juego es retro, así que, tampoco tengo tanto dilema en ese apartado. Prefiero hasta dejar de jugar que estar cambiando de sistema o tener que tener otro equipo en casa dedicado en exclusiva a ello. Me recuerda al martirio de hace más de 20 años cuando había que tener un arranque dual entre Windows 9x y Windows NT 4.0. Al final la conclusión era, si lo puedo ejecutar, o puedo conseguirlo, bien, si no, que le den. Un tema no muy lejano a este, en realidad.

Ahora bien, que si para instalar un juego a través de Origin en *nix (no sé ahora mismo si está disponible para *nix) hace falta virtualizar, no dudes que lo haré, si tanto empeño tengo.

El tema de Office es el claro ejemplo de la diversidad de usuarios o de fines. Está el usuario que sólo quiere, por ejemplo, un procesador de textos para formatear un texto y le importa un rábano todo lo demás; y quien quiere un programa para lo mismo, pero que cumpla sus expectativas de lo que debe ser un procesador de textos en su conjunto, el programa y la funcionalidad.

Por valer, hasta le valdría a un usuario de Windows usar Spread32. Total, hace lo mismo que cualquier hoja de cálculo.

Después de haber probado hasta en su día Star Office... bueno, cada uno sabrá qué es lo que quiere, pero no voy a explayarme sobre el porqué yo elijo uno u otro que ya es demasiado largo este mensaje y es un tema de apreciaciones personales.

Apreciaciones que, al fin y al cabo, son las que llevan a este hilo y elegir una u otra distribución *nix o quedarse en Windows, pero que ya vale

@caja roja Vale, ahora ya te entiendo mejor, en parte pensaba que querías seguir con tus flujos de trabajo y con software antiguo pero en *nix o BSD (Sí MAC es BSD)

Lo que dices de la plataforma de juegos. Toda la vida he cacharreado para hacer funcionar un juego (es lo que tiene no estar a la última en hardware, que siempre hay que toquetear aquí, allí y allá ) así que es no es un problema. Pero considerar a Windows como única plataforma de juegos, también es considerar a Windows como un fin en si mismo.

Tú lo que necesitas es una consola ;P (permíteme este guiño cómplice y no te enfades

No me enfado ni lo más mínimo, jejje, tengo un par de ellas, la más nueva es la xbox series, pero aún así como una parte de mis gustos en juegos son del tipo Age of empires, Command & Conquer Generals (antiguo como ves) , también me gusta cacharrear con emuladores y los FPS me gusta más jugarlos con teclado y ratón, siempre que puedo lo hago en el PC, al igual que los 2 últimos juegos que han portado a PC, como son God of War y Horizon Zero Down, los cuales juego igualmente desde el sofá con el mando inhalambrico.

Pero sí, te aseguro que si no me gustara cacharrear seguraramente solo tendría consola.


Y aunque no quieres en principio ir probando alguna distribución al final tendrás que probar por ti mismo si se adapata a lo que quieres, sabiendo por ejemplo que en debian es muy probable como te han comentado que tiene pinta de ajustarse a tus necesidades

PD. Estoy suscrito al hilo, me parece bastante interesante y a la espera de ver al final con que sistema acabas

Un saludo

‎luciferfran escribió:Y aunque no quieres en principio ir probando alguna distribución al final tendrás que probar por ti mismo si se adapata a lo que quieres

Probar, ya he probado con anterioridad..., hasta que te das cuenta que el acercamiento lo estás haciendo al revés y probar no es la solución. Primero se necesita conocer el sistema y qué hace, qué soporta, y luego ya se verá.

Probar, es mirar el dedo en vez de la luna. Probar es no ver el bosque detrás de los árboles. Y la luna o el bosque no es otra cosa que el sistema base y lo que pueda hacer o soportar.

Sí, tendré que probar, claro. Y más que probar, lanzarme, pero cuando vea claro qué ofrece y después de leer los manuales. En ese momento, si veo que me encaja, o si veo que no pero me atrae, o si veo que al final, con más o menos flexibilidad, la premisa es estar siempre a la útlima, pues igual digo, que le den a Debian y al final igual me quedo con *BSD. O al revés, igual acabo tragando y, venga, Windows, ande o no ande.

Necesito tener claro qué ofrecen antes de volver a tirarme a la piscina sin saber si tiene agua. Y si no tiene agua, pero es de mi gusto, pues... ya se verá.

‎luciferfran escribió:sabiendo por ejemplo que en debian es muy probable como te han comentado que tiene pinta de ajustarse a tus necesidades

Ojalá sea cierto. Tendré que leer y preguntar más por ahí antes de nada.

De todas formas, entre lo que tú has dicho y lo que ha dicho Esog Enaug, pregunto algo que puede resultar inocente pero que me ha dejado con la mosca detrás de la oreja. Algo que ya he leído con anterioridad sobre...

‎luciferfran escribió:ya que congela paquetería bastante antigua para que sea estable como una roca con todo más que probado.

Esto es como la letra pequeña de los contratos, e igual ahí estoy, o estamos entre todos, asumiendo algo que no es.

Ejemplo fácil: Firefox. No tiene por qué ser real. Es hipotético.

Una cosa es congelar los repositorios y, por ejemplo, no ofrecer más allá de la última ESR de Firefox, por estabilidad, y otra muy diferente es que el sistema permita, no sólo esa versión antigua, sino la ESR anterior a esa ESR (creo que sería la setenta y pico y la última es la noventa y pico).

Es decir, una cosa es ofrecer soporte a software "obsoleto" hasta cierto punto, y otra ofrecer absoluta retrocompatibilidad (salvando las distancias de pérdidas de funciones o cambios irremediables que no permitan la ejecución, a través del kernel), pongamos... para poder ejecutar Firefox 3.5.

Y saber si, para casos tan extremos, al final se necesitarían dockers, jails y similares como planteaba MiguelAngel LV.

¿Y para qué iba a querer ejecutar yo Firefox 3.5? Pues, desde probar compatibilidad con un desarrollo web, hasta... por mero gusto. No me juzguéis.

‎luciferfran escribió:PD. Estoy suscrito al hilo, me parece bastante interesante y a la espera de ver al final con que sistema acabas

Qué presión.

Aunque si la cosa queda en que Debian puede ofrecerme lo que busco, o es lo menos malo, tampoco tiene mucha intriga. Sería Debian.

De todas formas, no sería hoy, ni mañana, ni... Hay que leer, preguntar, el tiempo no es infinito y me llevará lo que me lleve. El tiempo ahoga, pero no me voy a volver a precipitar en enfrascarme en una en particular.

Para empezar, esta semana, la tendré en blanco. Cosas del verano y sus consecuencias. Y cuando no es el verano, es otra cosa. Ojalá pudiera dedicar más tiempo, pero esto va de muy poco en poco. Cada poco cojo conocimientos más profundos de *nix (quiero decir que algo ya tenía), pero entre vez y vez, también pierdo conocimientos. No puedo dedicar un tiempo pleno a esto y se olvida.

Depende mucho de la distribución, pero por regla general creo (al menos en Fedora que es el que uso), que los gestores de paquetes permite instalar versiones antiguas (si especificas versión), e incluso hacer downgrade si la nueva no te gusta, y bloquear las actualizaciones para los paquetes que quieras.
Además de repositorios de terceros por lo que raro es que no tenga el programa que buscas.

Esto tiene un límite dentro de la misma versión, pero si quieres usar cosas muy muy antiguas, pues siempre puedes virtualizar instalando una versión más antigua del SO, o por ej. en caso de Fedora puedes usar toolbox para crear instancias de versiones anteriores (como la que tenga la versión que buscas) y lo instalas desde ese entorno. Ya lo usé alguna vez, por un programa que no compilaba por la versión del gcc, fue crear entorno de versión anterior con la versión de gcc anterior a los cambios que rompían la compilación, instalar gcc normalmente desde sus repositorios (todo dentro de ese entorno creado con toolbox), y todo funcionó bien.

Como digo, depende de la distro.

‎darksch escribió:por ej. en caso de Fedora puedes usar toolbox para crear instancias de versiones anteriores (como la que tenga la versión que buscas) y lo instalas desde ese entorno. Ya lo usé alguna vez, por un programa que no compilaba por la versión del gcc, fue crear entorno de versión anterior con la versión de gcc anterior a los cambios que rompían la compilación, instalar gcc normalmente desde sus repositorios (todo dentro de ese entorno creado con toolbox), y todo funcionó bien.

¿"Desde", o "en" el entorno virtualizado?

No sé si te entiendo que en el entorno virtualizado corregiste las dependencias y luego lo ejecutabas en el sistema host o lo compilaste en el sistema virtualizado y lo ejecutastes después, aislado, en el sistema virtualizado.

caja roja escribió:

darksch escribió:por ej. en caso de Fedora puedes usar toolbox para crear instancias de versiones anteriores (como la que tenga la versión que buscas) y lo instalas desde ese entorno. Ya lo usé alguna vez, por un programa que no compilaba por la versión del gcc, fue crear entorno de versión anterior con la versión de gcc anterior a los cambios que rompían la compilación, instalar gcc normalmente desde sus repositorios (todo dentro de ese entorno creado con toolbox), y todo funcionó bien.

¿"Desde", o "en" el entorno virtualizado?

No sé si te entiendo que en el entorno virtualizado corregiste las dependencias y luego lo ejecutabas en el sistema host o lo compilaste en el sistema virtualizado y lo ejecutastes después, aislado, en el sistema virtualizado.

Ah no es que una cosa es la virtualización, y otra es el entorno que creas con toolbox, son cosas disintas.
Toolbox es una utilidad de comandos que se puede usar para crear entornos:
https://www.mankier.com/1/toolbox-create
Por ej. imagina que estás usando Fedora 35, y que la versión de la aplicación que quieres ya no está en sus repos, pero sí estaba en Fedora 31, pues ejecutarías más o menos (así de memoria):

A partir de ahí todo lo que hagas es como si estuvieras en ese Fedora 31, incluyendo sus repositorios, con instalaciones separadas del sistema principal, por lo que no hay peligro.
El comando pues tiene su chicha, cuestión de mirar su documentación, para crear, listar, gestionar y etc. los entornos.

@"‎darksch", ya entendí a la primera que era como los jails de *BSD. Lo que estás describiendo es exactamente igual.

Lo que yo quería saber es si el programa quedaba aislado en ese entorno (que ya lo has respondido). O dicho de otra manera, no puede interactuar con el equipo host. Llamémoslo host, para entendernos, aunque no sea una virtualización, como no lo son las jails, los dockers y similares. En resumen, la jaula.

Eso ya he/hemos estado viendo, por las jails, los dockers, los chroot, etcétera, que se podría hacer.

Ahora sabemos también cómo funciona en Fedora

La idea del hilo es conocer si tiene que ser así, sí o sí, en todas las distribuciones o se puede correr versiones anteriores, o viejo software, directamente en el host. Más que conocer, pues lo que dice la pregunta del hilo, si es posible o es un camino de mártires, bien sea con jaulas o similar o lo que sea. Saber qué se cuece.

Re-explicándome otra vez Si hay alguna distribución en la que no dependa la ejecución de software de un entorno operativo cerrado debido a querer mitigar en exceso el "dependency hell" (todo sea dicho de paso, que nunca he padecido en Windows (nunca entenderé por qué se pone como ejemplo a Windows)) y que, por ello, sólo se pueda correr software estrechamente ligado a la versión objetivo de una distribución por ser todas las dependencias estáticas al entorno operativo de esa distribución.

La explicación es más o menos "sencilla". Windows incorporó SxS (side-by-side), que es una tecnología que permite tener varias versiones de las mismas librerías. Por eso funcionan, quitando los posibles problemas de compatibilidad, programas antiguos, porque se tienen en el sistema las versiones de librerías que usara. Es muy típico tener en un sistema Windows no pocas instalaciones de las famosas "vcredist", que son las "Visual C++ redistributable", es decir las librerías de una versión de Visual C++. A saber cuántos vcredist habremos instalado en nuestros sistemas Windows, pues no es nada raro que un programa que ponga enlace o referencia a que instales antes un paquete de ese tipo antes de usarse, o lo hace por su cuenta durante la instalación (lo lleva integrado).


En otros SSOO no es distinto, si no funcionan programas antiguos en una versión, es porque su versión de las librerías no son compatibles, al no tener algo similar a SxS, pues hay que crear entornos donde suministrarlas.

Me estás explicado lo que ya conozco.

A mí WinSxS me parece una aberración descontrolada para solucionar un problema en el desarrollo de programas esperando versiones específicas en vez de incluirlas con el programa. Y si no están machacar las que haya en el sistema por las que yo necesito (con un par), lo que, a mis ojos, es una mala práctica en programación. Opinión sin ser programador, pero es lo que ocurría antaño, bueno, y no tan antaño.

De cualquier manera, he mentido. Si alguna vez he tenido "problemas" ha sido tan sencillo como proveer al programa de la librería necesaria. Pero han sido las menos, por eso no he tenido el problema, tal vez porque he elegido programas que no dependen de lo que haya en el sistema y ya lo incluyen o si no lo incluyen, tan fácil como poner la librería necesaria en su carpeta.

Y eso, claro, da una libertad de ejecución de programas bastante alta en Windows. Olvidándonos de WinSxS que, si mal no recuerdo, no existió hasta Windows 2000.

Win9x era un jungla y de aquellos polvos estos lodos en el entorno Win32/64.

‎darksch escribió:En otros SSOO no es distinto, si no funcionan programas antiguos en una versión, es porque su versión de las librerías no son compatibles, al no tener algo similar a SxS, pues hay que crear entornos donde suministrarlas.

Yo creo que sí es distinto. Mi experiencia en Windows no ha sido delegar a WinSxS. No tengo, ni de lejos, la burrada de versiones que tú tienes instalada.

El problema de *nix es que esto se exacerba al no enfocarse a librerías dinámicas y esperar sólo las del sistema.

Y todo el mundo está feliz de tener, al final, un sistema tan cerrado, que yo creía más abierto. Aunque hubiera que romperse los cuernos compilando, pero estoy viendo que ni por esas.

Desde la filosofía *BSD que, por "seguridad", no se permiten versiones obsoletas de librerías. Lo cual es entendible dado su objetivo de uso primario (FreeBSD y servidores), pero que limita al usuario a que alguien porte un programa, si quiere y se puede.

Hasta el resto que es estar a la última sí o sí.

Y ese resto es lo que quiero descubrir. Si es posible, sin morir en el intento, de ejecutar versiones, no viejas, siempre uso el término viejo pero me refiero a la versión que a mí me satisfaga, por las razones que sean (releed el hilo, que ya lo he explicado) en sistemas *nix. Si hay alguna forma.

Me parece muy bien que me vengas a leer el libro de Windows, darksch, pero te equivocas de persona, y sólo quiero saber lo que dice el asunto, si es posible, si alguna distribución deja, si no hay que morirse en el intento o si la única manera es usar jaulas.

Si el sistema ya veo como funciona, no hace falta que me leas la cartilla, pero no lo vi tan claro hasta que me empecé a enfrascar con *BSD.

En resumen, estoy intentando conocer si voy a tener la libertad de ejecución de programas que tengo en Windows o no, o qué métodos hay (que ya se han contado unos cuantos en el hilo) y si me compensan para adoptar *nix o qué distribución *nix.

Perdón si en este mensaje he resultado cortante. Será el calor.

Supongo que lo de "poner la libreria en la carpeta del programa" se puede hacer directamente o iniciando el programa desde un comando o script que modifique el path, añada enlaces simbolicos u otra cosa, pero nunca me he enfrentado a algo así.

Otra cosa que puedes hacer es crearte tus propias apps portatiles: https://blog.desdelinux.net/pkg2appimage-como-construir-nuestros-propios-archivos-appimage/. No se que tal funcionará, pero yo, en tu situación, me lo plantearía.

‎Esog Enaug escribió:Supongo que lo de "poner la libreria en la carpeta del programa" se puede hacer directamente o iniciando el programa desde un comando o script que modifique el path, añada enlaces simbolicos u otra cosa, pero nunca me he enfrentado a algo así.

Eso se podría hacer con chroot y que comenté. Lo que pasa es que la desventaja que estaba leyendo es que en esencia es replicar el sistema. Me faltó leer más en profundidad si bastaría con enlaces simbólicos. De cualquier manera me pareció demasiado para ejecutar un programa cualquiera.

Luego, el problema que comenté de que chroot es para programas de texto, pero no gráficos.

‎Esog Enaug escribió:Otra cosa que puedes hacer es crearte tus propias apps portatiles: https://blog.desdelinux.net/pkg2appimage-como-construir-nuestros-propios-archivos-appimage/. No se que tal funcionará, pero yo, en tu situación, me lo plantearía.

Me ha costado un buen tiempo de divertida investigación. Sabía que era posible pero no como

La verdad es que es muy interesante ese enlace.

Habría que ver los pros y los contras y estudiárselo bien, pero al menos abriría la puerta a que cada uno ejecute lo que quiera.

Y me gusta la frase que se cita de Linus Torvalds en la página de AppimageKit, y curiosa la conferencia porque dice prácticamente lo que yo digo aquí (https://github.com/AppImage/AppImageKit | https://www.youtube.com/watch?v=5PmHRSeA2c8&t=4m40s hasta el minuto:segundo 11:40):

So you actually want to just compile one binary and have it work. Preferably forever. And preferably across all Linux distributions.

Porque ahí está la miga de todo.

¿Por qué un usuario no va a poder ejecutar lo que quiera y tiene que estar constreñido a lo último o lo que la distribución le permita?

¿Y si tiene un bug?, dirían algunos, bueno, eso es cosa del usuario y allá penas. Me hago cargo, que para eso es MI entorno operativo. Evidentemente esto no vale para usuarios que no saben lo que hacen, pero al resto, que nos dejen un poquito de libertad.

https://www.youtube.com/watch?v=5PmHRSeA2c8&t=9m58s
Lo que ha tenido gracia es que del minuto:segundo 09:58 hasta el 10:14, dice exactamente lo que yo he dicho sobre el programa que utilizo en Windows sobre los bugs y las features, aplicado a glibc, pero bueno, aplicable igual.

En fin, Linus Torvalds diciendo lo que digo yo, hace ¡¡¡8 años!!! No ha cambiado mucho el panorama.

Ya no me siento una oveja tan descarriada

Que, por cierto, me suena de que es la conferencia donde dijo que dejaba el desarrollo para solucionar sus problemas de ira.

Gracias "Esog Enaug" y perdón "MiguelAngel LV" por minusvalorar la opción pues al final va a tener que ser con AppImage y similares.

Vamos viendo cual es la opción más plausible en GNU/Linux y que puede llegar a ser posible sin morir en el intento. Lástima que no lo sea para *BSD. Ahí me dejaría en bragas para ver qué distribución base GNU/Linux elegir que es por lo que más me estaba atrayendo de *BSD, como ya he dicho, y volvería a la locura otra vez. Lo que tengo claro es que tiene que ser un sistema base lo más pelado posible y de ahí ir construyendo mi propio entorno operativo, a mí manera (o distribución, podríamos llamarlo).

caja roja escribió: Lo que tengo claro es que tiene que ser un sistema base lo más pelado posible y de ahí ir construyendo mi propio entorno operativo, a mí manera (o distribución, podríamos llamarlo).

Medio en broma y medio en serio, te recomiendo echarle un vistazo a LFS. Es una "distro" que es un libro Un libro que te cuenta y explica como construir tu propia distro desde las fuentes, con lo que tienes todo el poder de decisión sobre todas las partes del SO pudiendo hacerlo todo lo liviano que quieras.

De todas formas sigo creyendo que para un SO ligero , lo mejor es partir de Debian o Arch y desde esa base engordarlo todo lo que quieras. Vas a lograr un sistema totalmente funcional, con capacidad de instalarle lo que quieras, bien documentado y con una cantidad inimaginable de software disponible.

‎Esog Enaug escribió:Medio en broma y medio en serio, te recomiendo echarle un vistazo a LFS. Es una "distro" que es un libro Un libro que te cuenta y explica como construir tu propia distro desde las fuentes, con lo que tienes todo el poder de decisión sobre todas las partes del SO pudiendo hacerlo todo lo liviano que quieras.

Y llegué a considerarlo... (aunque en este foro todos sabremos qué es, para los nuevos, LFS es Linux From Scratch).

Y más de una vez se me pasado por la cabeza cuando he probado distribuciones.

Porque está claro que no soy un usuario normal (aquí está este hilo para demostrarlo), pero, cuando estás probando distribuciones (light y ves lo recargadas de las no light), al final te das cuenta de que una distribución no es otra cosa que una capa de personalización de "alguien". Es decir, al final estás usando el sistema con las preferencias de otros para tus necesidades.

Y llegas a la conclusión de que como cada uno tiene una forma de hacer lo mismo, aprender y/o quedarte con una distribución es... ir a la fácil, pero un sinsentido. Lo que importa es el sistema base.

Así que, en esa búsqueda por usar algo "descargado" llegué a LFS. Pero es que LFS, al final, es saltar de la sartén al fuego. Es decir, pasas de, o usar una distribución premontada con cosas que no necesitas, recargada, etc; o tener que aprender a programar y conocer el funcionamiento completo de GNU/Linux. Si tuviera una ingeniería informática, igual ni me lo pensaba. Una cosa es conocer el sistema base (archivos de configuración, programas de sistema, etc) y otra eso, que es un nivel superior.

De todos formas, todo esto nos llevaría al mismo debate de que GNU/Linux debería estar unificado y la libertad del sistema.

En aras de que cada uno quiere hacer las cosas de forma diferente se complica todo, pero decidme que no sería más fácil tener una distribución unificada, primero desterrando el sistema de paqueterías de las distribuciones base (que luego usan el resto) y, como Linus Torvalds decía en esa misma conferencia, tirar de binarios; y luego cosas como que el sistema de instalación de esa distribución unificada fuera como el instalador de Windows 98 (salvando las distancias). Es decir, tú eliges qué tiene tu sistema final.

Algunos diréis, ¿y no hace eso el instalador de una distribución? Pues no, (no lo hacen ya ni los Windows desde... el 2000 o así), porque la distribución sólo te va a ofrecer aquello que está disponible para esa distribución. Y como cada distribución tiene su propia forma de hacer las cosas y su propio sistema base, no todo está disponible para todos, lo cual nos lleva a que (y ese también es el tema de este hilo) que habría que desterrar el sistema de paquetería para poder tener un sistema totalmente libre y que el usuario no tenga las restricciones que tiene a la hora de instalar software.

Conseguir eso es imposible y lo único que me recuerda es al meme aquel de "hay X estándares y no funciona ninguno, vamos a crear otro", pero sigue sin arreglar el problema y sólo crea otro más.


Divago, pero he fantaseado con que si tuviera recursos (conocimientos, tiempo, lo que sea), haría algo así.


Total, que entre Pinto y Valdemoro, por eso, al final, recaí en *BSD porque al menos tienes una base estable en el tiempo y pelado y luego es cosa tuya ponerle cosas, pero el enfoque de *BSD, pues también tiene sus limitaciones, incluso más, con el tema de software disponible y el enfoque al servidor.

Por eso este hilo, porque acaba uno tal que así. No puedo poner imágenes: http://www.emoticons.free.fr/smileys/Em ... nting2.gif



Una cosa final en este tema. Cuando antes he dicho "Es decir, al final estás usando el sistema con las preferencias de otros para tus necesidades", alguno seguro que ha pensado, ¿y no es eso Windows?. Pues sí, y sobre todo en los últimos tiempos (ya no es como era Windows 98), y de ahí buscar la alternativa en *nix e intentar resolver los dilemas del software en este hilo.

‎Esog Enaug escribió:De todas formas sigo creyendo que para un SO ligero , lo mejor es partir de Debian o Arch y desde esa base engordarlo todo lo que quieras. Vas a lograr un sistema totalmente funcional, con capacidad de instalarle lo que quieras, bien documentado y con una cantidad inimaginable de software disponible.

Y te lo tomo como consejo. Y me alegra ver, como dije, que hay ahora un Arch32 (eso me permitiría hacerme a él virtualizando antes de instalarlo de verdad) porque lo consideré al ser un sistema que te lo ibas montando tú.

De Debian no tenía yo esa imagen de configurabilidad. Recuerdo haberme bajado el netinstall, probablemente en la época que probé Antix, pero algo me frenó y no sé qué fue.

No sé, probablemente fuera la locura que se montó a través de SystemD y la variabilidad de distribuciones que eso provocó.

Ahora veo que existe Devuan que no usa SystemD y dicen en su web que da más retrocompatibilidad con programas. No sé cuánto de cierto tiene.

Pero el tema SystemD vs otro INIT, da para un hilo aparte y al final no sé si habrá opción y usar hoy otro sistema sería una vía muerta de aquí a X tiempo.

Otro problema de la diversidad de GNU/Linux.

‎Esog Enaug escribió:Aunque siempre encontraras ese bug estúpido que te alegre la vida un rato: este finde pasado instalé gnome-boxes para probarlo (muy facil de usar pero con MUY pocas opciones de configuración) y el muy XXXX me tocó la configuración de la swap y me jodió la ejecución de algunos juegos bajo wine.

Otro ejemplo de las burradas del los programadores... ¿Por qué un programa tiene que tocar el sistema base y tocar algo elegido por el usuario como la swap?

En fin.

Ya tenéis otra biblia para leer Perdón.

@caja roja

Después de todo el periplo tendríamos que ver con qué programa y situación se te da el caso de tener que hacer esas magias negras de usar versiones anteriores no soportadas.

Quizás no llegues a encontrarte con esa situación en años... Y tengas que cambiar antes de ordenador jeje.

Espero que el cambio no sea nada traumático

Un saludo!

Y puede que tengas razón, sólo quiero tener la posibilidad, ver que es posible, cómo.

Pero mira, estaba pensando enviarte esto, tal cual, como respuesta y he caído en un programa viejo que ayer mismo estaba mirando porque lo estaba utilizando para hacer un diseño.

Lo uso en Windows y sé que está para GNU/Linux, pero claro, ya es más viejo que la pana (la versión equivalente que uso en Windows es más vieja aún; tengo otra más nueva, pero es que para lo que hace no me compensa la de recursos que pide). No sé si estará disponible para todas las distribuciones actuales, si es que acaso llega a estar disponible.

Para FreeBSD, por descontado que no (no está ni en freshports listado, diga lo que diga la web), aunque pudiera llegar a funcionar, tal vez, con la capa de compatibilidad para binarios de GNU/Linux.

Xara LX (Xara Xtreme for Linux)

Claro, la suerte es que se distribuye como binario casi listo, pero sí que pide una dependencia muy vieja. Pero luego está el tema de que esa dependencia por razones X no esté disponible o vete a saber en distribuciones modernas.

‎luciferfran escribió:Quizás no llegues a encontrarte con esa situación en años...

Y puede ser, pero no quiero deseo verme en un callejón sin salida porque no se puede. O tener claro que no se puede y ya.

‎luciferfran escribió:Y tengas que cambiar antes de ordenador jeje.

El cambiar de ordenador no significa que cambie mi filosofía al respecto. No sé a qué te refieres. ¿Qué tendría más espacio para virtualizar más?

El problema lo tendría igual si quisiera utilizar X programa no disponible en repositorios actuales o con dependencias obsoletas.


ACTUALIZACIÓN:

Estoy leyendo ahora el foro y aquí tenemos un claro ejemplo de todo el problema y nada menos que con Steam:
https://github.com/ValveSoftware/Proton/issues/6051

Recomendaciones de usar flatpack, bla, bla, bla....

Y por la misma razón que mencionaba Linux Torvalds en el video de la conferencia que puse (y que al final me vi entero): glibc

Sí lo de Steam es un buen jaleo la verdad. Lo bueno que es un programa actualizado y mantenido.

El que quieres usar tu hace 15 años que no se actualiza, el tema de cambio de ordenador es que posiblemente cuando vayas a cambiar por ejemplo solo se pueda instalar dentro de los Windows del 11 hacia arriba y puede que ya solo admita programas de 64bits, lo mismo puede pasar en Linux, total Mac los mató hace tiempo los 32 bits... Y lo normal es que lo hagan el resto de SO, algún día incluso seguramente ya sean ARM y solo programas mantenidos puede que lleguen a funcionar...

En estos casos quizás toca cambiar el flujo de trabajo y buscar otro programa de diseño que tenga soporte.


Un saludo

‎luciferfran escribió:El que quieres usar tu hace 15 años que no se actualiza

El que no reciba actualizaciones es lo de menos. No necesita ninguna característica especial, es para lo que es y ya.

Otra cosa es que no tenga soporte para poder ser compatible, pero nunca se hizo otra versión de Xara LX para GNU/Linux. Llegaron hasta ahí y ahí se quedó.

‎luciferfran escribió:, el tema de cambio de ordenador es que posiblemente cuando vayas a cambiar por ejemplo solo se pueda instalar dentro de los Windows del 11 hacia arriba y puede que ya solo admita programas de 64bits, lo mismo puede pasar en Linux, total Mac los mató hace tiempo los 32 bits... Y lo normal es que lo hagan el resto de SO, algún día incluso seguramente ya sean ARM y solo programas mantenidos puede que lleguen a funcionar...

Bueno, eso ya es un cambio de arquitectura, o dejar de soportarla.

Siempre quedaría la virtualización o emulación. Con eso cuento como último recurso, siempre.

‎luciferfran escribió:En estos casos quizás toca cambiar el flujo de trabajo y buscar otro programa de diseño que tenga soporte.

Es decir, que me estás robando mi libertad de elegir qué programa ejecutar

No, a ver, el caso de la arquitectura, vale, a día de hoy no ejecuto nada en 16bits, pero un programa que no tiene ninguna pega...

Este mismo programa, en su versión Windows, la que uso son 30MB. La más nueva... varias centenas. ¿Para qué? Para hacer lo mismo. Y ya no hablo de cambios de arquitectura, que se puede entender que el programa engorde, sino para meter cosas superfluas e innecesarias... para mi uso. Para otros serán útiles, no digo que no, para mí no. Y no me quejaría si no fueran obligatorias. O sea, no son componentes que si quieres los instalas y si no no.

Pongo otra vez el ejemplo de la hoja de cálculo, siempre puede usar alguien Spread32 (es el ejemplo opuesto), vale para lo mismo. Pero claro, hay que valorar si se quiere un programa con apenas funcionalidad, una suite ofimática completa o una suite ofimática recargada y las diferentes suites alternativas, si tu programa no funciona.

Cambiar de programa, se puede, ¿claro que así? Si no queda otra...


Pero de todas formas me estás poniendo el caso extremo (arquitectura), ya he dicho anteriormente, que, mientras sea compatible..., si no lo es, evidentemente, habría que buscar alternativa.

Pero no es menos cierto que, vuelvo a repetirlo, esto se exacerba en *nix. No puedes quedarte con un programa que cumple tus expectativas (dejando de lado la arquitectura u otras incompatibilidades insalvables).

Si algo he aprendido es que nada es para siempre. Un ejemplo muy claro es si usabas un programa de MS-DOS pues no se ejecuta en SSOO de 64-bit, y te tienes que buscar la vida. Y así va a ser con todo. Lo llaman "compatibles", pero claro eso llega hasta cierto punto, y más allá de dicho punto toca buscárselo.

Me autocito del último mensaje, darksch:

Pero de todas formas me estás poniendo el caso extremo (arquitectura), ya he dicho anteriormente, que, mientras sea compatible..., si no lo es, evidentemente, habría que buscar alternativa.

Ya he puesto bastantes ejemplos sobre a qué me refiero

Buenas.

Cuando hablas de usar versiones viejas, por las razones que quieras, yo veo fallos de seguridad. Si lo que te preocupa es que algo falle, recuerda que algunos masocas disfrutamos de comernos esos fallos, en mi caos, la pena más grande es que me encanta BSD, pero BSD y jugar no es posible. Al final, uso FreeBSD para un día que tengo pocas ganas de jugar y pongo el BSD al día. Pero uso uso, al sistema, le doy cero. Toca seguir esperando que se siga dando caña a Steam en BSD, pero como la mayoría de usuarios de BSD lo hacen en entornos de desarrollo y trabajo, es normal que esté realmente lenta la cosa. Y yo desgraciadamente nunca aprendí a programar.
Aunque leas el UPDATING de ports y src, siempre hay fiesta en current.

Steam, o jugar, es lo de menos, aunque pudiera haber más complicaciones en *BSD, por descontado. El problema es la disponibilidad general de software..., que en *BSD, se agrava, bien sea por su orientación al servidor, a estar la última, a la seguridad.

Más que preocupar que algo falle, y cuando digo algo, no poder instalar algún programa, es que sea insalvable, incluso aunque haya gente dispuesta a comerse el tarro. Seamonkey "se salva" por la cabezonería de un usuario, pero el problema y los métodos para resolverlo evidencian el problema del software en *nix y la cerrajón a las versiones viejas y/o "consideradas obsoletas", incluso por una simple librería.

Eso al final me hizo preguntar abiertamente aquí esto. Me estaba dando muchas comidas de coco porque al final todo *nix peca de lo mismo. Lo de Seamonkey me escamó bastante.

Y me fastidia porque, encantar, a ver, tampoco, porque sobre todo ha sido leer sobre FreeBSD, más que usarlo, pero, sí, a mí me estaba encantando, no sé si decir "también", por el concepto de sistema base sólido en el tiempo, de tener los conceptos claros y bien documentados (bueno, bien, tampoco del todo que hay cosas "dadas por hecho" o incluso mal expuestas que te tienes que leer otros tantos manuales para aclararlo) y el haber invertido tiempo en él para "nada"...

En current puede que haya fiesta, pero eso de estar siempre como en fase beta como que tampoco

Me quedo con que me ha ayudado a aclarar bastantes conceptos *nix leyendo los manuales de *BSD, o, más que los manuales, las lecturas paralelas, en estos meses (no continuamente, de rato a rato, cuando se podía), pero aún así...

Me encantó ver que por aquí había un usuario de *BSD Aunque veo que tampoco es de uso diario

Sobre el tema de las versiones viejas vs seguridad, ya respondí. Sencillamente, no estoy de acuerdo. Y digo lo mismo, no voy a argumentar sobre el tema de la seguridad porque, en este tema, para mi desgracia, soy de opinión opuesta a la opinión general.

caja roja escribió:Nunca acabaré de entender esa obsesión con que la última versión es la más segura.

No voy a argumentar porque al final tendríamos un flamewar y una desviación absoluta del tema pero no estoy de acuerdo con la afirmación "última versión === seguridad".

Lo único que, ese tema, al final, limita aún más las posibilidades de software en *nix :_(


En fin, a ver si pasan estos días de calor y sigo preguntando "por aquí y por allá" (en las sugeridas Debian, Arch, etc), porque no he encendido ni el PC más que a horas intempestivas, y un ratito.

Gracias a todos por vuestros comentarios