Sign up with your email address to be the first to know about new products, VIP offers, blog features & more.

Repasando la relación de Ubuntu con Upstart

Recientemente ha habido un gran revuelo debido a que el equipo de Debian, después de mucho tiempo de discusiones acaloradas, ha decidido cambiar su demonio de inicio System V por Systemd frente a la alternativa Upstart. Puedes leer el anuncio aquí.

Acto seguido, Mark Shuttleworth ha anunciado que Ubuntu también se pasará a Systemd.

No voy a entrar a valorar la idoneidad de la medida, ni qué “init” me parece mejor (pese a las ventajas que pueda tener Systemd me parece que sigue muy poco la filosofía Unix), sinó que lo que realmente me ha llamado la atención es hasta qué punto Ubuntu apostó por Upstart.

Allà por el 2006 en Ubuntu 6.10 decidieron empezar a usar Upstart, además y para evitar problemas optaron por darle compatibilidad con los scripts de inicio de SysV. Así, Upstart era capaz de gestionar tanto los scripts en formato propio como los scripts de SysV.

Este tipo de retrocompatibilidades permite integrar fácil y rápidamente una herramienta nueva que sustituye a otra con ciertas garantías de estabilidad. Conforme las aplicaciones van actualizando sus scripts, se crea una situación de duplicidades que dificulta mantener el control sobre los scripts de inicio. Por ejemplo, si deseo modificar o deshabilitar un servicio debo buscar en /etc/init, en /etc/init.d o en los correspondientes /etc/rc.d y en cada caso deberé actuar de forma distinta. Claro que existen herramientas gráficas para editar los servicios que se iniciarán, tan fácil que ni te enteras de cómo anda el asunto, pero inténtalo en un servidor.

¿Es deseable mantener ésta situación?

Para quien conozca cómo funciona SysV sólo debe aprender cómo manejar Upstart. Para quien desconozca ambos debe aprender a usar ambos. Y en cuanto termine la migración sólo se debe aprender a usar Upstart.

Si falta determinación en establecer un fin de soporte al init antiguo habrá quien ni se moleste en migrar los scripts. Si se alarga demasiado, a parte de las molestias a los usuarios y administradores que se ocasionaran, se creará una imagen de ineficacia que uno no desea que se asocie a su marca.

¿Durante cuánto tiempo hay que mantener este tipo de retrocompatibilidades?

No sabría establecer qué margen de tiempo puede ser el adecuado. Imagino que puede depender de los ciclos de actualización, por ejemplo, en Archlinux apareció Systemd por el repositorio testing allà por enero de 2012, aunque no he encontrado cuándo pasó a ser un paquete del repositorio core sí que se anunció como sistema por defecto en el CD de instalación el 13 de octubre de 2012 manteniendo compatibilidad con los scripts de SysV. El 4 de febrero de 2013 se aunció el fin de la relación entre SysV y Archlinux eliminándolo de los repositorios apenas 4 meses más tarde desde que se empezó a usar por defecto.

No recuerdo que la experiencia fuera muy traumática, claro que hubo que dedicarle un poco de tiempo a aprender cómo manejar Systemd y es probable que algo fallara (tampoco en Archlinux se preocupan tanto de la estabilidad como en Debian) pero desde entonces sólo hay una manera de gestionar los scripts de inicio. No hay que adivinar dónde estarán ni cómo se estarán usando.

Con Ubuntu he tenido una experiencia diferente. La verdad que hace años que lo instalo a familia y colegas pero a nivel personal no le he metido las garras a fondo, por lo que la sorpresa la tuve hace poco trasteando en un VPS donde opté por una imagen de Ubuntu 13.10 (pensé sobretodo en la posibilidad de tener paquetes más actualizados que en Debian).

Configurando y documentando el proceso me topé con que no sólo había “/etc/init” para los scripts de Upstart sinó que se seguía manteniendo y usando la estructura de SysV. Para deshabilitar Apache tuve que usar “rc-update” pero para deshabilitar el demonio de bluetooth tuve que crear un “.override” en “/etc/init”.

¿Cómo voy a documentar eso si se supone que va a cambiar (SysV a Upstart) en cualquier momento? Tanto “/etc/init” como “/etc/init.d” están plagados de scripts y de enlaces. Me han dado ganas de usar la imagen de Debian ante tamaño despropósito.

Bueno, ahora que han decidido migrar a Systemd, seguro que va a haber cambios, pero estamos hablando de que han mantenido ésta situación durante 8 años! ¿Es esto lo que entienden por user friendly? Estoy convencido de que en Debian tardarán mucho menos en migrar completamente a Systemd.

El descubrimiento me ha tenido reflexionando y me ha hecho preguntarme: ¿Realmente apostó Ubuntu por Upstart?

Parece que apostaron más por un mínimo esfuerzo y muchas luces y colores que han terminado en una implementación a medias y ahora que en Debian les van a solucionar la papeleta pues mejor cambian para ahorrarse trabajo (lo que me parece legítimo) pero que no se cuelguen tantas medallas entonces por lo que no llegaron a terminar.

Me hacen dudar también de su idoneidad como distribución para un servidor, línea en la que supuestamente apuestan como posible negocio, o incluso de que Mir (bueno, de esto ya dudaba) no vaya a convertirse en el próximo espectáculo de luces y colores encima de un castillo de naipes.

Como curiosidad puedes consultar el resúmen que muestra Ohloh sobre la actividad en el desarrollo de Systemd y Upstart.

¿Cuál ha sido tu experiencia con Upstart?

  • Pingback: Bitacoras.com()

  • Llorenç, excelentísimo artículo. Compañero tuyo en Linux Hispano y sólo puedo agradecer tu gran primer artículo.

    Con respecto a lo que dices, mi opinión es que Canonical, y por ende Ubuntu, no quiere complicarse mucho la vida y en sigue la estela de Debian. Canonical está inmerso en la convergencia de su sistema operativo y está centrando sus esfuerzos en crear aplicaciones en QT y QML y promocionar su SDK propia (Ubuntu SDK). Viendo el cambio que ha realizado la comunidad Debian han debido pensar que a la larga las aplicaciones críticas migrarán a Systemd y sólo tendrán que clonar su repositorio.

    Repito, excelente artículo y muchísimas gracias por colaborar con nosotros.

  • Pingback: Repasando la relación de Ubuntu con Upstart()

  • Linez Linux

    Antes de nada felicidades por el artículo.

    Supongo que Ubuntu apostaría por upstart por ser una creación propia y desarrollada a la medida de sus necesidades/pretensiones.Corrígeme si me equivoco.
    No puedo entrar en aspectos técnicos sobre si es mejor o peor porque no tengo los conocimientos necesarios,pero presupongo que Ubuntu adaptó upstart a lo que ellos pretendían en un “init” para su distribución.

    Sobre la idoneidad de Ubuntu para servidores tampoco tengo conocimientos,pero muchos servidores de grandes empresas han migrado a Ubuntu últimamente,entre ellos Google.
    Supongo que el soporte técnico que brinda Canonical también tendrá mucho que ver en eso.

    Y sobre quién hará antes la migración completa a systemd,parece que Canonical pondrá varios de sus programadores a la disposición de Debian para que la migración sea lo más rápida posible,con lo que supongo que llegará bastante más pronto que tarde.
    Saludos.

  • Muchas gracias, espero mejorar y que las musas no me abandonen.

    Como dices, seguro que Upstart les ha servido, siendo un poco abogado del diablo hasta creo que para forzar que necesitaran del uso de su soporte técnico (tampoco quiero desprestigiar a ningun administrador de sistemas).

    Pongo un ejemplo, modificas un script de upstart para que un servicio que tienes instalado no arranque de forma automática. Un día, te das cuenta que algo pasa cuando tienes menos memoria disponible y te vuelves loco para averiguar porqué. O descubres que el servicio se ha vuelto a iniciar solo o llamas a soporte. Hasta la versión 1.7 (04/03/2013) una actualización del paquete te podía sobreescribir la modificación del script.

    O es malície o es dejadez, no se me ocurren muchas alternativas. Pero la fama de Debian junto a un Soporte mínimamente decente debe venderse muy bien.

    No acabo de entender porqué no lograron enganchar a desarrolladores (o porqué no quisieron). Como muestran en Ohloh el mes que más desarrolladores participaron fueron 6. Y eso que casi tuvieron la exclusiva del init por eventos durante 4 años y podrían haber logrado que se estableciera en el nuevo estándar.

    Luego aparece Systemd y en la mitad de tiempo se desarrolla mucho más rápido, Con hasta 40 participantes distintos en un mes.

    Si cerraron la participación al desarrollo para mantener una rigurosa calidad no pinta que les haya salido muy bien cuando al final van a renunciar a su producto en favor de otro que ha seguido una política totalmente distinta.

  • Muchas gracias Manuel, espero poder hacer aportaciones mejores a ésta comunidad.

    Pienso que si hubieran hecho un producto que convenciera a la comunidad posiblemente hoy no tendrían que preocuparse de dedicar esfuerzos a migrar otra vez y podrían centrarse igualmente con sus otras metas. Pero tal como ha evolucionado el panorama y lo costoso que debe ser remar en otra dirección que tu mainstream, al menos demuestran que son capaces de adaptarse.

    La idea que se traen entre manos con su SDK es otra apuesta arriesgada, estoy ojeando y me llevo la sensación de que vuelven a intentar reinventar la rueda. De todas formas Investigaré más a fondo.

Leer entrada anterior
Tasa Google

Cerrar