Tecnología, Internet y juegos
183 meneos
3368 clics
Líder de Debian: snappy puede hacer a Ubuntu menos compatible con el resto

Líder de Debian: snappy puede hacer a Ubuntu menos compatible con el resto

En Linux.com, Swapnil Bhartiya le ha hecho una interesante entrevista a Neil McGovern el flamante líder de Debian, en el que además de hacer un repaso por su biografía y hablar de las responsabilidades que conlleva su nuevo puesto en el proyecto, comenta temas de actualidad relativos al desarrollo de la distro y de una de sus hijas como es Ubuntu

| etiquetas: debian , snappy , ubuntu
84 99 4 K 495
98 comentarios
84 99 4 K 495
Comentarios destacados:                  
  1. #1 --352386-- *
    ¡Debian y Ubuntu en el titular! Meneo al canto.
    8 K 57
  2. #2 --316392--
    En un principio dudé bastante de snappy, pero cada vez me gusta más. Habrá que ver como se comporta. De funcionar como toca, resolvería muchos problemas de dependencias rotas y demás. Esto haría que los sistemas fuesen más seguros pese a tener en ocasiones paquetes duplicados.

    Si al final resulta que es bueno, ¿no debería mejor Debian adoptarlo? Al ser Debian la distro madre parece que sea impensable que pueda implementar funcionalidades de Ubuntu o de cualquier otra distro.
    2 K 19
  3. Shotokax #3 Shotokax
    #2 APT funciona muy bien. No creo que haya necesidad de reinventar la rueda y fraccionar aún más el mercado. Si había alguna mejora posible, que la hubieran hecho sobre APT. No es factible sacar un producto nuevo cada vez que se pretende mejorar uno existente. No entiendo estas cosas.
    15 K 102
  4. Sofrito #4 Sofrito *
    Pues me parece una buena idea eso de instalar aplicaciones sin preocuparte por las dependencias. Ése ha sido siempre el punto flojo de Linux.
    7 K 40
  5. #5 --125581-- *
    No me molan ni APT ni Snappy. No entiendo la fragmentación APT/YUM - deb/rpm . Hace tiempo que deberían haber montado una API y base comunes de verdad, y que hicieran el rebranding que les dieran la gana, como en los BSD.

    Relacionado: queue.acm.org/detail.cfm?id=2349257
    4 K 37
  6. K-M #6 K-M
    #5 La respuesta al por qué no ha sido así la tienes, como en tantas otras ocasiones, en las tiras de xkcd: xkcd.com/927/
    13 K 91
  7. Mr_Vodo #7 Mr_Vodo
    #4 Precisamente esa es la belleza de linux, que funciona como una máquina si sabes engrasarla como toca. Lo de sacrificar precisión a cambio de inestabilidad creía que era uno de esos problemas más característicos de otros sistemas y un paso hace tiempo superado.
    4 K 32
  8. #8 apol
    Con el resto? xD
    0 K 6
  9. PythonMan8 #9 PythonMan8
    #3 pues continua utilizando apt. ¿quién te lo impide?

    Los ingenieros de Ubuntu prefieren Snappy y no creen posible mejorar apt porque está diseñado con otro propósito totalmente distinto.

    Android ha demostrado que se puede hacer una distribución de linux desde cero y triunfar a lo grande. En Ubuntu son libres de hacer lo que crean conveniente. Si Google se hubiese puesto a discutir para intentar llegar a un consenso con todo el mundo sobre cómo debía ser Android todavía estarían en la versión 0.1 en vez de haber vendido más de 2000 millones de dispositivos y hacerse con el 90% de los móviles del mundo.
    9 K 75
  10. #10 --125581-- *
    #6 Ya, el nuevo standard, ni falta me hace verlo. Pero me refuero a un barrido completo:

    - Fuera rpm
    - Fuera dpkg
    - Nuevo formato de paquetes de verdad una vez realizado lo anterior.
    - Configuración comun para todos los Linux. Se acabó eso de tener mysql en /etc/ o /var/lib/ según la venada de cada distro.
    - El kernel, GLIBC y Xorg FUERA del sistema de paquetes. Es-ta-bi-li-dad por versión. A lo BSD. Lo demás, sí, como paquetes.
    - GNU+Linux unificado a lo BSD, sin separar uno de otro. Al menos, estandarizado entre distros.
    - Documentación estricta. A lo BSD. Que no quede nada sin documentar. ¿Los de GNU son maś de INFO? Pues infos.
    - Systemd no me gusta, pero si unifica todo, es preferible a 20000 sistemas de configuración distintos.
    - Fuera YaST, Mageia Control Center y similares. Forman parte del pasado.
    - Phonon/Gstreamer y demás, fuera. Gstreamer debería ser el estándar. Phonon no pinta nada, no tiene un backened de códecs siquiera.
    - Gente de Gnome y Plasma, unificad los backends y poned las capas que querráis encima de GTK3 / QT5 para la configuración.
    11 K 76
  11. #11 --128651-- *
    #10 Yo apoyo tu planteamiento al 100%, pero, como en todas partes, los egos de mucha gente están por encima del bienestar común o, en este caso, de la calidad del software. Y lo digo con conocimiento de causa como Ingeniero de Software, que en este mundo hay mucho "mi código es bueno y el tuyo es una puta mierda".

    No obstante, también puedo entender que tanto DEB como RPM son buenos sistemas y que nadie quiera desprenderse de "lo suyo". Personalmente me gusta más DEB y me encantan los PPA, pero como cada distro va a lo suyo, veo complicada una convergencia...
    3 K 25
  12. sorrillo #12 sorrillo
    #9 ¿Hoy Android sí es Linux?
    4 K 50
  13. #13 --125581-- *
    #11 No soy ingeniero, soy técnico de sistemas, pero no hace falta ser universitario para reconocer un buen diseño, y el de OpenBSD es el que debería copiar el mundo GNU/Linux, empezando por la documentación y que claramente no hace falta crear monstruos enormes con 1000 funcionaliades redundantes para tener una base mínima muy usable, como KSH comparada con Bash, o sed vs head/tail y demás.

    Sé que GNU no es UNIX pero...
    1 K 21
  14. K-M #14 K-M
    #10 El problema es el de siempre: Poner de acuerdo a todo el mundo es imposible. Cada grupo piensa que su filosofía ofrece cosas que las del de al lado no tiene. E incluso si se lograse unificar todo llegaría alguien que pensaría que las cosas se harían mejor de otra manera, se haría un fork y vuelta a empezar.
    Sin una única voz directora no se puede unificar todo el software libre pero una voz directora es precisamente la antítesis del mismo.
    4 K 39
  15. Hanxxs #15 Hanxxs
    #4 ¿Mande? apt-get install loquequieras y te instala todas las dependencias.
    5 K 30
  16. #16 --125581-- *
    #14 Es que el mundo GNU casi casi es reimplementar UNIX en LISP/Guile :-P

    Como con GNU/Guix. O el propio Emacs. De hecho Guile es lenguaje scripting "de facto" de GNU. Llevan otra filosofía y usando el kernel Linux montan un frankestin raro.

    En OpenBSD y demás, pues es obvio que amén de las herramientas UNIX, perl es la navaja suiza recomendada.

    Al menos es como lo veo. Tienden a sobrecomplicar las cosas.
    0 K 10
  17. #17 --125581--
    #15 ¿Sin que las librerías nuevas se carguen la versión favorita de tu juego anterior y metan la nueva aunque no te guste?
    3 K 29
  18. Sofrito #18 Sofrito *
    #15 En general es así. Pero hay aplicaciones que no te puedes instalar directamente desde el apt-get. Por ejemplo: ffmpeg. Vale, puedes instalarte una versión "reducida" desde apt-get. Pero si quieres la versión "full", tendrás que instalarla manualmente y te aseguro que no es fácil.

    Lo cojonudo sería encontrar un paquete "ffmpeg" con todas las dependencias que necesites sin preocuparte de nada. Creo que de éso va el concepto que están desarrollando. Si no me equivoco.
    1 K 17
  19. #19 --125581-- *
    #18 Eso hacen en OpenBSD. Meten FFMPEG con todo, incluso las fuentes. ffmpeg / ffplay y las librerías en sí. Y encima no sé com lo hacen pero ocupan menos que en el mundo GNU con documentación y todo.

    Pero no, con snappy vas a tener las dependencias en el paquete y con un sistema de deduplicación evitarás tener la misma librería duplicada.
    0 K 10
  20. Hanxxs #20 Hanxxs
    #17 Si mantienes tu sistema actualizado con apt-get update eso que dices no tiene ningún sentido.
    3 K 19
  21. #21 --125581--
    #20 Sí tiene.

    Tienes un RPGv 1.20 . Sacan la 1.30. No te gusta.

    La 1.20 depende de libv.so.12 . La 1.30, de libv.so.12.1

    Sacan VLC, el nuevo. Lo quieres. Está compilado contra libv.so.12.1

    Pues bien, si quieres el VLC nuevo con su codec ultraHD4K, te va a actualizar el juego ya que depende de la librería libv.
    3 K 26
  22. #22 dotromas
    #10 Podrías proponerlo en sitios como Reddit o en listas de correo de Linux donde quizás podrían tomar nota de algunas medidas o también incluso discutirte los motivos por los que no se hace de otra forma actualmente. Linux esta cambiando y seguira cambiando con el tiempo y no sabemos cuales serán los avances o transformaciones que le esperan en los proximos años. Debemos recordar que Linux es Unix-Like, pero también tiene caracteristicas de otros sistemas como Plan9 por ejemplo. Es posible que implementen algunas de esas ideas, pero también es posible que implementen otras soluciones mejores que esas ideas.

    Y también hay que recordar que Linux puede estar entre los primeros cuando se habla de Estabilidad/Robustez (RHEL por ejemplo), y también puede estar entre los primeros en Rendimiento Bruto o incluso en Seguridad. Pero igualmente es mejorable.
    0 K 6
  23. Hanxxs #23 Hanxxs *
    #21 Pues no, en 15 años usando Linux nunca me ha pasado. Ojo, que a lo mejor el raro soy yo.
    3 K 23
  24. #24 --125581--
    #22 GNU/Linux usa las herramientas GNU y sigue esa filosofía, y GNU's not Unix. Es una reinplementación de UNIX extendida a lo LISP.

    Vamos, que no es UNIX, ya lo dijo Stallman. Tomaban Unix como base y lo ampliaban, pero muchas veces innecesariamente, puesto que muchas de las Coreutils se implementan con comandos rápidos de pocos caracteres, no más de 10.
    0 K 10
  25. zeioth #25 zeioth *
    Pienso que están siguiendo los movimientos mas lógicos, lo mismo opino en cuanto a Mir/Xorg. El rendimiento y el hacerle la vida mas sencilla al usuario son lo primero en un sistema operativo.
    0 K 9
  26. #26 --125581--
    #23 ¿No? ¿Seguro? ¿Puedes usar programas de Ubuntu 10.04 directamente en la 14? ¿O estás atado a las versiones de tu distro?

    ¿Qué pasa si un juego antiguo en Linux es preferible a la versión existente a los repositorios?
    3 K 37
  27. #27 --166178--
    #10 Has descrito todas las mierdas por las que no uso Linux
    1 K 17
  28. RojoVelasco #28 RojoVelasco *
    #21 Eso es totalmente falso. En Linux no hay juegos :troll:
    6 K 50
  29. #29 --125581--
    #14 "Sin una única voz directora no se puede unificar todo el software libre pero una voz directora es precisamente la antítesis del mismo."

    Bueno, en #5 dan argumentos convincentes. Una base para un SO siempre es necesaria.
    0 K 10
  31. #31 Itrio
    #26 Hombre, ese ejemplo que pones de 'juego antiguo' (o programa antiguo) que es mejor en versiones anteriores, es un poco 'raro'. De todas formas, si es libre y está el código, siempre puedes recompilarlo estáticamente con las librerías 'viejas' (si es que con las nuevas no funciona por alguna razón) y apañado. Pero vamos, yo los problemas con librerías normalmente me los he encontrado con versiones nuevas que no están todavía en la versión oficial de la distribución y si para instalarlo hay que actualizar librerías, pues ahí sí puedes tener problemas.

    De todas formas, para esto hay dos enfoques:
    - Las librerías son del 'sistema' --> Te toca adaptarte y los programas deben usar las librerías que hay instaladas. La ventaja es la optimización, tanto de espacio en disco, como en memoria. La desventaja es que estás supeditado a la evolución de las librerías, tanto para mantener software viejo, como para instalar software nuevo.
    - Cada programa lleva sus librerías incluidas. Facilitas la instalación y 'aíslas' cada programa del resto del sistema. Duplicas espacio en disco y memoria y cuando haya actualizaciones (bugs, seguridad...) de las librerías, es un caos porque hay que actualizar todos los programas que las usan y siempre queda el riesgo de que alguna aplicación no se actualice y siga funcionando con una librería defectuosa.
    1 K 14
  32. #32 --125581--
    #31 Compilación estática donde los binarios al compilarse solo cojan el código necesario de la librería para funcionar y listo, como Plan9. Y funciona.
    1 K 17
  33. #33 Itrio
    #32 Esa sería la 'opción 2' que he comentado, pero no resuelves el principal problema que tienes cuando haya que actualizar las librerías estáticas con las que has compilado los programas. O bien reinstalas todos los programas o puedes dejar un agujero porque un programa no se haya actualizado y siga usando una librería con algún error conocido.

    Yo no sé cuál es mejor solución, creo que depende de qué programas. Quizá para juegos o programas 'locales' pueda ser mejor usar compilación estática, pero para servidores o utilidades del sistema (web, correo, bases de datos...) prefiero que las librerías estén compartidas y centralizadas sabiendo exactamente qué usa cada uno.
    1 K 14
  34. Jakeukalane #34 Jakeukalane *
    #12 #8 Android no es una distro Linux. Sólo lleva el núcleo, no tiene el userland GNU y te deja atado de pies y manos a la hora de controlar el dispositivo. Tener núcleo tiene, es Linux, pero no tiene la experiencia de usuario de cualquier distribución.

    Si Canonical quiere idiotizar ubuntu mal va. Pero creo que no es ese el camino que están haciendo, sino uno menos agresivo, más próximo a lo que realmente representa el software libre. Se ha visto también en los móviles con ubuntu.

    #9 Chrome OS es una distro linux y encaja con todo lo que has dicho, exceptuando por ahora la diferencia numérica de dispositivos.
    0 K 12
  35. #35 Pingocho *
    #26 Si usas Ubuntu es mejor que uses los programas publicados para tu versión. Si te pones a instalar versiones diferentes de los programas, lo más probable es que éstos requieran una versión diferente de las librerías que usa el sistema operativo, así que al final terminas haciendo el mismo trabajo de resolver las dependencias que hace APT, pero a mano.

    En ese caso Snappy termina siendo como el Google Play, que no permite instalar apps en determinadas versiones de Android por las versiones de sus librerías.
    0 K 10
  36. Jakeukalane #36 Jakeukalane
    #31 Todo eso que habláis en #20 y #21 PASA, pero se resuelve "sin ningún problema" con chroot. Te montas un nuevo apartado y ahí instalas el juego/librería conflictivo. ¿Cómo se hace? Ni puta idea...
    0 K 12
  37. Jakeukalane #37 Jakeukalane
    #28 te salva el emoticono...
    0 K 12
  38. Jakeukalane #38 Jakeukalane *
    #10 me da a mí que te apañarías mejor con BSD directamente...

    Pero hay algunos puntos que son un +1000 (phononn, Gnome+plasma, etc)
    De algunos no entiendo suficiente para opinar, pero suenan a algo que diría el de "Linux sucks", no sé si conoces esos vídeos, pero seguro que sí.
    0 K 12
  39. Jakeukalane #39 Jakeukalane
    #8 necesitas una explicación o es un chiste personal?
    1 K 1
  40. #40 Pingocho *
    #5 Lo de la fragmentación APT/YUM es cuestión de gustos de los desarrolladores y usuarios. Yo prefiero APT con paquetes .deb, por su sólida resolución de dependencias, velocidad y facilidad para adicionar repositorios, y porque tiene los mejores gestores de paquetes (se abre el debate). Yo adoptaría APT como estándar en Linux, pero como se trata de una comunidad libre, otros prefieren YUM y RPM, y quieren adoptarlo como estándar. Esa es la gran ventaja y a la vez la gran desventaja de Linux: eres libre de crear tu propia distro con lo que quieras y, si llega a ser popular, imponer tu estilo sobre parte de la comunidad (fragmentar la comunidad).
    0 K 10
  41. #41 Pingocho *
    #10 Puedes hacer tu propia distro y fragmentar aún más a Linux. Es justamente por eso que se ha fragmentado tanto: cada cierto tiempo aparece alguien como tú que no está satisfecho con las distros existentes y cree tener la "solución definitiva", así que decide crear su propia distro y reunir la mayor cantidad de seguidores posible. Al tiempo, otro creyendo tener la "solución definitiva" ve tu distro y decide que podría estar mejor, así que crea su propio fork. Y así sucesivamente.

    Eso se debe a que Linux es una comunidad, no una empresa con dirección como Apple o Microsoft. Es imposible hacer que una comunidad tan grande, diversa y libre siga al unísono los "designios" de un autoproclamado "iluminado".
    0 K 10
  42. kahun #42 kahun
    #10 Parece que no entiendes el concepto de distribución ... además me hace gracia como nombras a BSD como si fuese la panacea de la unificación cuando tienes FreeBSD, NetBSD, OpenBSD, DragonflyBSD, ... cada uno de su padre y de su madre. Si lo que quieres es un Windows, usa Windows, yo quiero libertad para poder elegir YaST, Mageia Control Center, o lo que me plazca
    0 K 10
  47. #47 --125581--
    #46 sed 5q
    2 K 20
  48. #48 --125581--
    #42 "FreeBSD, NetBSD, OpenBSD, DragonflyBSD"

    :palm:

    Son sistemas operativos diferentes, con diferente kernel, API, todo.
    2 K 31
  50. Seta_roja #50 Seta_roja
    #49 define compatible... :palm:
    0 K 10
  51. #51 eduardor2k
    #10 #11 La belleza de Linux es que podeis montar vuestra propia distro con todo eso y nadie os va a decir nada. :-)
    0 K 7
  52. #52 PatrokIo
    #36 no se si estás trolleando o intentando ser de ayuda xD
    0 K 6
  53. Jakeukalane #53 Jakeukalane
    #52 intentando ser de ayuda. He querido desde siempre hacer un chroot pero cuando pregunté como se hacía me respondieron tan crípticamente que no hubo manera. Cierto es que me respondieron en inglés... Tampoco he encontrado ningún manual. Pero cierto es que si tienes que instalar por ejemplo Amarok 1.4 en Ubuntu 15.04 lo que tienes que hacer es un chroot o fakeroot y ahí instalas todos los debs que necesitas. Y así no te rompe ni gstreamer ni otras librerías de kde... Lo sé porque lo he intentado hacer y es uno de los motivos por los que sigo en Ubuntu 11.10 (aparte de porque no sé hacer buenos respaldos). Además con chroot podría usar aplicaciones que utilizan una libc moderna incluso en ubuntu 11.10.

    Así que si alguien sabe como...
    0 K 11
  54. #54 PatrokIo *
    #53 ¿has probado a leer el manual? xD
    1 K 12
  55. Jakeukalane #55 Jakeukalane
    #43 Gracias por la info.

    Por cierto, ¿sabes hacer chroot? -> #36 #53
    0 K 11
  56. Jakeukalane #56 Jakeukalane *
    #54 Sí. Es tan breve que lo podría pegar aquí. Cuando decía que no había encontrado ningún manual me refería a "manual de verdad/tutorial"
    0 K 11
  57. #57 PatrokIo
    #56 nah, eso lo decía ya con ánimo de trolleo xD los manuales en ciertas cosas de linux suelen caben en una servilleta y además están mal hechos.
    1 K 17
  58. Shotokax #58 Shotokax
    #9 ¿con qué propósito está hecho APT "distinto"? No sé, puede que haya cosas que se me escapen, pero es un gestor de paquetes igual, y funciona muy bien, la verdad.

    No sé a qué te refieres con "distribución de Linux". Si te refieres a distribución de GNU/Linux, Android no lo es. Si te refieres a sistema que lleva núcleo Linux (aunque creo que es un mod) sí, pero no es desde cero en absoluto, utiliza software ya hecho por otros.

    Por último, tu razonamiento es muy cortoplacista. Si no te pones de acuerdo con nadie desarrollas más rápido, lógico, pero fragmentas y divides el esfuerzo, lo cual es malo a largo plazo, y es malo para combatir al software propietario.
    0 K 11
  59. #59 rocambolescus
    #43 También puedes compilar y correr aplicaciones GNU en Windows. Y en MacOS. Y en BSDs. Y en Solaris. Y un largo etc. Por eso es importante diferenciar. Hay que usar el término completo GNU/Linux para referirse a entornos como Debian. Porque si no, en cuanto metes un núcleo FreeBSD con userland GNU (www.debian.org/ports/kfreebsd-gnu/), o un núcleo Linux con userland Android, la gente empieza a correr en círculos gritando.
    1 K 16
  60. #60 rocambolescus
    #7 El camino de Ubuntu lleva a la maravilla de Windows, donde si tienes 300 juegos y todos usan la misma versión de DirectX cada uno instala su propia copia porque para qué reutilizar.
    2 K 19
  61. #61 darkdefender
    Me preocupa mucho leer noticias de GNU/Linux en Meneame y ver opiniones rotundas de gente que no sabe de lo que habla.

    Apt y las dependencias es la solución elegante y mantenible para un sistema que ha de ser estable y seguro. ¿Qué ucurre cuando una librería tiene un bug de seguridad y la has instalado 80 veces como un estático en 80npaquetes y ni lo sabes?

    Puede haber alternativas para pero buscan otros fines como la simplicidad en la instalación sin tener que gestionar repositorios cohesionados. Con apt puedes pero todas las app y lbrerias del repo deben ser mantenidas coherentemente.

    En fin, que cada cosa es buena para unos fines y pretender que snappy reemplace a apt es descabellado.
    0 K 6
  62. #62 mcosta
    #21 Que digan lo que quieran, pero tienes toda la razón. O lo que es más divertido, RPGv 1.30 depende de libv=1.30. No le vale la 1.30.1. Y para que de más risa, hace conflicto con libv-ext<1.30.

    Ahora no es tan comun, pero me ha tocado descomprimir el paquete a mano y poner la libreria en /usr/local/lib, o peor, ~/.local-lib y jugar con LD_PRELOAD.

    Con lo facil que sería dejar que se instalaran juntos y que apt-get se comportara como aptitude y desinstalara las librerias de las que nadie depende ya. Siempre he pensado que es por falta de QA para asegurar que las dos librerias se pueden instalar lado a lado. La combinación de versiones explota y los fallos por usar una mala combinación serian inmanejables.
    0 K 6
  63. #63 ElAnonimo
    #12 Android no es Linux nunca, y quien te lo diga miente.

    Android tiene kernel Linux, pero ni los usuarios y permisos se gestionan como lo haría cualquier GNU/Linux.

    Y ahí es donde se evidencia que deberíamos tener una palabra para definir el conjunto de distros y otra para el kernel. Poder aclarar qué es "ser linux" :-S
    0 K 6
  64. #64 ElAnonimo
    #21 #62 Muchos juegos comerciales para Linux van con las librerías que más cambian en un directorio propio, si tu quieres hacer lo mismo es muy sencillo:

    Descargas tu libv.so.12 y la metes en el juego, es fácil porque todo deb, rpm o tgz es un comprimido y se puede extraer fácilmente el archivo que quieras.
    $ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./RPGv1.20
    Profit!
    Según el juego es posible que necesites reemplazar el . por la ruta al juego. También puedes montarte un directorio de librerías "obsoletas" y apuntar la variable allí para todos los juegos.

    Ahora, que debería haber una herramienta que permita hacer eso sin consola ni conocimientos. Pues igual que bumblebee debería de ir ya integrándose en los entornos de escritorio para poder hacer doble click.
    0 K 6
  65. #65 --128651-- *
    #51 Creo que no te enteras. Si yo creo mi propia distro con todo eso, al final lo único que hago es añadir un competidor más como aquí: xkcd.com/927/

    Se trata de que todas las distros compartan sistemas de paquetes y parámetros de configuración (como el ejemplo de MySQL de #10 ), no de seguir rizando el rizo.
    0 K 9
  66. #66 ElAnonimo
    #53 Hoy día puedes usar LXC, o docker que es más sencillo y son un par de comandos.

    La mayor dificultad de hacer chroot es crear el directorio base, tienes que "instalar" la distro en un directorio dentro de tu equipo (esto pasa también con LXC, lo que ofrece Docker es un repositorio de imágenes ya preparadas para LXC).

    (Pero, dado que chroot es lo más tradicional, ahí va)

    En debian y Ubuntu puedes usar debootstrap:
    wiki.debian.org/es/debootstrap

    Para yum también hay opciones, básicamente se descarga el paquete "base" (que indica la distribución y versión que es) y luego sobre eso se hace yum de las cosas que quieras meter en el nuevo root, aquí lo hacen para centos5 con un poco de cabeza lo cambias por otra cosa basada en yum:
    systemadmin.es/2012/06/instalar-el-honeypot-ssh-kippo-en-un-chroot

    El modo vago es utilizar imágenes ya preparadas, como estas:
    download.openvz.org/template/precreated/
    Aunque son para otra cosa, deberían cumplir.
    # curl download.openvz.org/template/precreated/suse-13.1-x86.tar.gz | tar -xvz
    (Y ya tienes ¿Open?Suse 13.1 en el directorio)

    Para entrar en el chroot no podía ser más trivial, pero necesitas ser root:
    # chroot /directorio/chroot

    Por otro lado, el servidor gráfico y de sonido están arrancados fuera del chroot, por lo que nada de ejecutar programas multimedia (como juegos).
    wiki.gentoo.org/wiki/Steam#32-bit_chroot_on_amd64 (este no lo he encontrado en castellano, pero son todo comandos y ficheros a copiar, cambiando rutas claro).

    Con docker lo tienes más sencillo:
    # docker pull tianon/steam (esto es una imagen configurada con un SteamOS y steam instalado y listo para ejecutar, puedes buscarte otras de interés)
    # docker run -d tianon/steam steam
    (Teóricamente ya te lo hace todo él: descarga imágenes de sus repositorios, las monta en un directorio suyo y cuando haces el run utiliza los namespaces de Linux para crear una jaula, la prepara para acceder al entorno gráfico y lanza el comando que has pedido en ella).
    1 K 17
  67. kahun #67 kahun
    #48 Capitán obvio al rescate!

    ¿Y? Estás pidiendo al mundo Linux lo que el mundo BSD no tiene, ¿si el mundo Linux quiere tener 3 sistemas de paquetes y dos sistemas de inicio aunque compartan el mismo kernel qué problema hay?
    0 K 10
  68. #68 --125581--
    #67 no te enteras. Cada bsd es un so DIFERENTE incompatible con los otros . no tienen nada que ver.
    0 K 10
  69. #69 --125581--
    #67 problema gordo. Incompatibilidad y reinventarse la rueda a lo tonto. Duplicar esfuerzos .
    0 K 10
  70. kahun #70 kahun
    #68 Parece que no te enteras tu, ¿y? gran parte de muchas distribuciones Linux tampoco tienen nada que ver unas con otras, se llama diversidad, ¿y?

    OpenBSD nació como un fork de NetBSD, si es incompatible con NetBSD es simplemente porque quisieron, ¿qué diferencia hay entre eso y que el sistema de paquetes de suse no sea compatible con el de ubuntu?
    0 K 10
  71. #71 --125581--
    #70 obsd fue por política. Es un so completo DISTINTO enfocado n la seguridad. Las diestros son un chiste comparado con el curro de Theo.
    No aportan nada, sigue siendo el mismo kernel pero con tu GestorTM de paks revokucionario y cambios en $prefix .
    0 K 10
  73. #73 --125581--
    #33 Las librerías estáticas no se actualizan. Los binarios son autocontenidos.
    0 K 10
  74. AsK0S1t10 #74 AsK0S1t10
    Después de leer todo el hilo, todavía me extraña que se critique a quien prefiera un sistema tipo: ejecutar -> siguiente -> desmarcar toda la mierda que se pretende instalar por debajo -> siguiente -> siguiente -> irte a jugar con el niño. Las librerías dinámicas es un gran concepto, pero en muchísimas ocasiones prefiero "tirar" HDD (que me sobra siempre) y tenerlas redundantes, a incompatibilidades de programas que nada tienen que ver entre sí. Y lo que más valoro es el tiempo.
    1 K 19
  75. #75 Itrio
    #73 Ya, por eso es un problema cuando en la librería que has usado para generar el binario estáticamente se detecta un error. Si la librería está incluida en el binario, no queda otra que actualizar el binario entero para corregir ese error. Si esa librería la usan 100 programas y los 100 se han compilado de forma estática, pues tienes que actualizar 100 programas. En cuanto 1 de esos 100 programas no lo actualices, ahí se mantendrá el error, que depende del programa que sea podrá ser o no asumible.
    0 K 12
  76. #76 --125581--
    #75 Actualización con las deltas binarias. Solo bajarías los cambios respecto a la instalada.

    es.wikipedia.org/wiki/Xdelta
    0 K 10
  77. #77 Itrio
    #76 ¿Y eso qué tiene que ver? Vale, optimizas el tamaño a descargar, pero sigues dependiendo de que 100 programas se actualicen para corregir un problema, mientras que si las librerías son dinámicas e independientes del programa, actualizas la librería y lo solucionas para los 100 programas.
    0 K 12
  78. kahun #78 kahun
    #71 Claro, los desarrollos promovidos por cada distribución (date una vuelta por todo el software que mantiene Red Hat por ejemplo), los programadores a tiempo completo que aportan al kernel y a otros tantos proyectos, los parches que mandan a todos los proyectos, ... un chiste todo.
    0 K 10
  79. kahun #79 kahun
    #71 Por cierto, te cambio el consejo que te di antes, si tanto te gusta OpenBSD, pues usa OpenBSD, nadie te obliga a usar Linux.

    El rendimiento de OpenBSD comparado con Linux también es de chiste.
    0 K 10
  80. #80 --125581-- *
    #78 Ahm. Por eso Google con Android ha barrido más que RH, Suse, Canonical e IBM en toda su vida.

    Vamos a ver, o tiran todo abajo y crean LA distro o todo seguirá penosamente implementado, como un bazar donde todo son hacks guarros funcionando a patadas por decirlo finalmente.

    #79 GNU/Linux, pero como sistema general es un asquete, desperdigado en ciertos de distros con nula documentación en muchos casos.

    Por no hablar de que los manuales de Bluez o ifconfig por ejemplo se quedan cortos comparado contra OpenBSD. Y encima hay que aguantar inetutils vs ip(1).

    Un despropósito. Un barrido gordo hacía falta, aunque sea con Systemd.
    0 K 10
  81. #81 apol
    #39 Es un chiste personal.

    Si bien Debian estuvo a la cresta de la ola, sus normas extremadamente estrictas han hecho que la innovación sea imposible. Este podría ser otra muestra de como Debian va muriendo lentamente, que sigue tratando de disrupción cualquier novedad.
    0 K 6
  83. #83 --125581--
    #82 Hay expresiones similares en longitud.
    0 K 10
  85. Seta_roja #85 Seta_roja
    #72 si hablas del funcionamiento del hardware, porque mencionas compatibilidad con windows o mac, que es software? :-P
    0 K 10
  87. kahun #87 kahun
    #80 RH, Suse, Canonical ... dominan ampliamente el mercado de servidores. Google ha barrido con Android porque era un mercado incipiente en el que se podía entrar, en el mercado de escritorios domina Windows y eso no va a cambiar tan fácilmente, costó 7 años desbancar a Internet Explorer, ¿te crees que la gente va a cambiar de sistema operativo así como así? pero no te preocupes, seguro que pasan a usar todos OpenBSD en masa.
    0 K 10
  88. kahun #88 kahun
    #69 Suplir distintas necesidades y gustos, ofrecer distintos servicios, ...
    1 K 20
  89. #89 --125581-- *
    #84 Las expresiones son como las de Vim o Perl, regex de toda la vida.

    Hay que conocer un mínimo la verdad, siempre son útiles.

    Tail es entendible, head tiene delito.
    0 K 10
  90. #90 dotromas
    #71 hombre en Linux tienes distros cómo un ucLinux que son algo más que una distro normal. Bsd tiene cosas buenas pero en general creo que es mejor Linux. Linux puede ser tan o más seguro que Openbsd. Puede usarse para tiempo real en tantas plataformas como Netbsd. Puede tener rendimiento similar o superior a Freebsd. Puede ser tan robusto o estable cómo bsd (Rhel o similares). No creo que tantos sitios de computación crítica en los que han adoptado Linux o están en proceso puedan estar equivocados. Bsd es bueno para ciertas tareas pero no es todo terreno ni tampoco supera claramente a Linux en esas tareas. De todas formas me gustan muchas cosas de Freebsd sobretodo (y alguna de los otros bsd). Aun así Linux ira mejorando o cambiando con el tiempo, tal y como lo ha ido haciendo.
    0 K 6
  91. #91 --125581-- *
    #90 "Linux puede ser tan o más seguro que Openbsd."

    Intrínsecamente, no. Con Grsec y demás, sí, pero un fallo de Grsec manda todo al cuerno.

    En OpenBSD vigilan muy mucho que todo sea seguro, por diseño, sin necesidad de armaduras.

    Por cierto, tampoco me gusta FreeBSD ;) . Aquí en OpenBSD somos de binarios para todo (y de una documentación exquisita hasta para la API de C o la cosa más nimia).

    "man afterboot", con eso lo digo todo.
    0 K 10
  92. #92 dotromas *
    #91 si. Hablo de distros específicas o ya configuradas para seguridad. Openbsd es más seguro en su instalación por defecto pero luego tienes porta externos que pueden tener más vulnerabilidades y no cuenta con tantos sistemas de seguridad como los que hay para Linux o incluso proyectos como trustedbsd en Freebsd.
    0 K 6
  93. #93 --125581-- *
    #92 "luego tienes porta externos que pueden tener más vulnerabilidades y no cuenta con tantos sistemas de seguridad como los que hay para Linux "

    Olvidas la compilación segura hecha por los de OpenBSD, la cual se puede realizar con systrace(8) si te da la gana ;)

    "Ports" poco, esto no es FreeBSD. Aquí paquetes binarios parcheados y con las funciones inseguras sustituídas para que nada acceda donde no debe.

    De hecho en OpenBSD recomiendan instalar paquetes por algo. No, no son los que te encontrarás en distrochapuzas como Arch donde cogen todo vanilla aunque reviente a pedazos.

    El tener "tantos" sistemas como seguridad como Linux no te garantiza nada. Observa:

    news.ycombinator.com/item?id=9538437

    La seguridad ha de ser intrínseca, con funciones seguras de base. Si depende todo de SeLinux o AppArmor, en unos años se puede liar una muy gorda.
    0 K 10
  94. #94 dotromas *
    #93 en ese enlace tiene una medida para la seguridad en VM fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control#How_To_
    Selinux seguramente tendrá problemas aun no descubiertos, pero existen muchas otras tecnologías y medidas de seguridad complementarias (mirar hardened gentoo para hacerse una idea). También Linux apuesta si quieres por la criptografía e incluso firma de binarios. Y en tema de ataques ddos o similares (además del software existente) ya hay nueva implementación para el tema de redes que vendrá en próximos kernel (Xia).

    La seguridad en base a corregir bugs principalmente es una Utopía o limita bastante el uso de tu sistema.
    0 K 6
  95. #95 --125581--
    #94 "La seguridad en base a corregir bugs principalmente es una Utopía o limita bastante el uso de tu sistema."

    No tiene por qué , aquí las cosas funcionan: X sin root, machdep.aperture a 0, implementación correcta de redes, PF que mitiga mucho el DDOS de serie...

    No es una utopía. Ah, que no podré usar 4 librerías de C diferentes , o 30 schedulers. Vaya por dios.
    0 K 10
  96. #96 dotromas
    #95 Linux puede usar también X sin privilegios de root (gracias a systemd-logind). Además, me imagino que el nuevo Wayland tendrá ese problema resuelto. La implementación de redes no solo es interesante que sea robusta/segura, sino que además ofrezca rendimiento (la nueva implementación Xia para Linux mejorara el ya buen rendimiento en redes Linux y también su seguridad).

    ¿Crees que los de OpenBSD "limpiarían" de bugs programas tan grandes como KDE? No me vale que usan otro gestor/windowmanager porque podriamos poner de ejemplo otro tipo de programas. Aún que cambien todas las funciones "inseguras" de C podrían tener otros miles de bugs que no detectarían ni tienen tantas medidas de seguridad para contrarrestar problemas graves de seguridad como Linux o FreeBSD. Lo que yo creo es que OpenBSD tiene un uso minimo (en comparación con Linux o incluso con FreeBSD), se utiliza principalmente como sistema para hacer de router/firewall y pocos servicios mas (con lo que solo es necesario una instalación basica y como mucho 4 paquetes muy concretos, reduciendo mucho las vulnerabilidades y ataques).

    Es como si hablamos de QNX o Minix incluso (sistemas muy minoritarios y muy especificos, además de reducidos en funciones, por lo cual para su basico uso son estables y seguros). Si tuvieran un uso mas extendido y realizaran mas tipos de tareas, les lloverían los ataques y bugs.

    Yo personalmente prefiero un sistema que me sea muy polivalente y bueno, para que no tenga que disponer o conocer 3 o 4 sistemas operativos para según que quiera hacer (jugar, montar servidor, programar, etc...). Me gusta UNIX y Linux es muy Unix-Like, aunque tenga cosas distintas (/proc, systemd y alternativas, etc). Que a ti te gusta un sistema muy basico/minimo, pues también tienes opciones como TinyCore Linux con busybox, ash shell, un X minimo distinto, etc... Incluso te puedes fabricar tu propio Linux al estilo LFS y hacerlo a tu medida.
    0 K 6
  97. #97 --125581-- *
    #96 Confundes sistemas mínimos como TinyCore con sistemas correctos y aún siendo minimalistas.

    Puedes tener OpenBSD un XFCE4 con toadd + dbus para montar y reconocer USBs y lo que te plazca correctamente, y Bash/ZSH si te da la gana, pero el tema no es ese.

    El tema es que en Linux faltan estándares y una dirección clara, amén de una absoluta y bochornosa falta de documentación al ir GNU por un lado y Linux y las distros por otro.

    Proyectos como GNU Bash y Gnu Emacs son las excepción. ¿Y lo demás ? Todo está tan segmentado en distros que es imposible que nada tenga documentación como en un OpenBSD donde TODAS las páginas del manual existen para cada comando , binario, script y archivo de configuración.

    Solo tienes que ver la faq, "man afterboot", man resolv.conf de OpenBSD contra sus contrapartes de GNU, donde muchas veces el intento de documentación falla estrepitosamente. O cuando simplemente no lo está. O la existencia de ifconfig/inetutils y sistemas de arranque que chocan entre sí.

    Sobre disponibilidad en los paquetes de OpenBSD tengo una parte enorme de CPAN, y bueno, OpenSSH nace aquí básicamente, no tenemos por qué ser una especie de monjes de clausura, aunque dicen que atenerse a lo que trae la "base" de OpenBSD es bueno.
    0 K 10
  98. #98 dotromas
    #97 Es cierto que la documentación en Linux a veces es regular, pero tampoco esta tan mal la documentación Info. Linux o las distribuciones aprovechan esa libertad y "anarquia" para personalizar o crear distintas versiones de sistemas con algunos paquetes en común (que también muchas veces son modificados o parcheados). Existen las distros "binarias" o basadas en paquetes y otras basadas en código principalmente, en general tienes para elegir o puedes personalizar la tuya propia.

    Todo esto puede tener su lado bueno y lado malo, pero como he dicho antes Linux no es perfecto y tiene que mejorar o innovar mucho mas. Los sistemas BSD tienen sus cosas que pueden ser buenas algunas de ellas y que no vienen por defecto en las distros Linux o directamente no se aplican en Linux (como el concepto de "sistema base" y su mantenimiento). También hay otros sistemas muy "basicos" y con buenas caracteristicas en ciertos aspectos/ambitos (como Minix), pero yo no los considero como sistemas para uso versatil o ni siquiera como sistemas para uso "domestico" (incluso en ese supuesto ámbito donde son buenos, Linux también lo es seguramente). Por eso FreeBSD es quizás el BSD que me gustaría tener si Linux no existiera. Solaris es otro sistema Unix muy polivalente y bueno, pero al no ser software libre/abierto pues para mi esta descartado (y creo que a día de hoy a sido superado en tecnologías y posibilidades por Linux; Solaris 11 no es ni ha sido tan novedoso ni bueno como lo fue en su día Solaris 10).
    0 K 6
comentarios cerrados

menéame