Microsoft añade ‘systemd’ al subsistema Windows para Linux

Microsoft y Canonical se han unido para añadir compatibilidad con systemd al subsistema de Windows para Linux, lo que permitirá instalar un mayor número de aplicaciones compatibles.

1. Sobre Systemd

Systemd es una aplicación de software de Linux que actúa como gestor de sistemas y servicios para inicializar los daemons/servicios durante el arranque del sistema operativo. Systemd también soporta herramientas que permiten a los administradores de Linux gestionar y controlar fácilmente estos servicios una vez iniciados.

Como systemd es responsable de lanzar todos los demás servicios, se ejecuta como el primer proceso (PID 1) creado por el kernel de Linux en el arranque. Todos los demás servicios de arranque inicial son iniciados y gestionados por systemd, como se muestra en el árbol de procesos de Ubuntu.

2. WSL el gestor de sistemas y servicios

Como WSL utiliza actualmente init como gestor de sistemas y servicios, las aplicaciones de Linux que requieren systemd, como Snap, microk8s (Kubernetes) y systemctl, no funcionan correctamente.

3. Compatibilidad

Microsoft y Canonical anunciaron que la última versión preliminar del Subsistema de Windows para Linux en las compilaciones Insider de Windows 11 ahora es compatible con systemd, lo que permite instalar aplicaciones que requieren el gestor de servicios.

«La compatibilidad con systemd requería cambios en la arquitectura de WSL. Como systemd requiere el PID 1, el proceso init de WSL iniciado dentro de la distribución de Linux se convierte en un proceso hijo de systemd», explicó Craig Loewen, de Microsoft, en un nuevo anuncio.

«Debido a que el proceso de init de WSL es responsable de proporcionar la infraestructura para la comunicación entre los componentes de Linux y Windows, el cambio de esta jerarquía requirió repensar algunas de las suposiciones hechas con el proceso de init de WSL».

Si estás ejecutando una compilación de Windows 11 Insider, puedes actualizar a la versión preliminar de WSL 0.67.6 o posterior utilizando el comando wsl –update. Una vez que haya terminado de actualizarse, puedes comprobar la versión instalada utilizando el comando wsl –version, como se muestra a continuación.

Ahora necesitas habilitar systemd lanzando tu distribución de Linux WSL deseada y añadiendo las siguientes líneas a /etc/wsl.conf:

[boot]
systemd=true
Como la carpeta /etc es propiedad de root, necesitas usar sudo con tu editor de consola favorito para editar el archivo. Por ejemplo, sudo vi /etc/wsl.conf.

Hay que tener en cuenta que este proceso debe hacerse para cada distro que desee habilitar systemd.

4. Más sobre el trabajo de Microsoft con Canonical

Para obtener más información sobre cómo funciona systemd en WSL y cómo le permitirá ejecutar más aplicaciones en WSL, puede ver este vídeo de Craig Loewen de Microsoft y Oliver Smith de Canonical.

Fuente: www.somoslibres.org

systemd 246 incluye soporte para volúmenes BitLocker de Microsoft

systemd

systemd es el init de la discordia que ha dividido a la comunidad de usuarios de GNU/Linux. Sus defensores argumentan que es un instrumento que permite aprovechar al máximo el potencial del sistema operativo y elogian su enfoque modular, mientras que sus detractores lo acusan de quebrantar la filosofía Unix y de ser un “Windows gratis”, y posiblemente para muchos así sea a partir de hoy viendo lo que trae la reciente versión 246 del init. Con todo, es el init utilizado por la gran mayoría de distribuciones Linux.

Sí, systemd 246 ya está con nosotros con al menos un par de contribuciones relacionadas con Microsoft, la compañía detrás de Windows, Microsoft Office, el framework .NET y el popular editor de código Visual Studio Code. Pero además de mencionar lo que podrían ser las partes más morbosas de este lanzamiento (por quién está detrás de algunas contribuciones), también abarcaremos otras novedades de interés.

Para empezar, de systemd 246 sobresale el hecho de que systemd-journald soporta comprensión mediante Zstd para los ficheros journal del init, cosa que se ha implementado de forma similar para los coredumps recolectados por systemd-coredump. Por su parte, los montajes Tmpfs que son creados automáticamente por systemd tienen ahora un tamaño y límites de inodo aplicados, de un 50% de la RAM para ‘/tmp’ y ‘/dev/shm’ y de un 10% de la RAM para otros montajes.

systemd-homed es una de las incorporaciones más interesantes que ha recibido el init (o framework de sistema, según se vea) en los últimos tiempos, y aunque para algunos puede resultar intrusivo, es un componente que ayuda a facilitar la administración segura del directorio personal del usuario. A partir de systemd 246 el backend de LUKS puede descartar automáticamente los bloques de sistema vacíos cuando el usuario cierra la sesión, además de ofrecer una mejor protección contra los potenciales escenarios de doble cifrado de datos y soportar el desbloqueo de los directorios de usuario utilizando tokens de seguridad FIOD2.

Continuamos, ahora sí, con la parte “polémica” de este lanzamiento, las contribuciones relacionadas con Microsoft. Por un lado, el propio gigante de Redmond ha introducido un cambio que permitirá exponer parte de la información de la máquina anfitriona a los contenedores, mientras que por otro systemd-cryptsetup puede a partir de la versión del init que nos ocupa activar volúmenes de Microsoft BitLocker durante el arranque.

¿Qué más hay en systemd 246? Pues nos encontramos con cosas como el nuevo comando systemd-xdg-autostart-generator para generar archivos de unidad de systemd a partir de ficheros de inicio automático XDG con extensión ‘.desktop’, que también puede “ser usado para permitir que la instancia de usuario systemd administre servicios que son inciados automáticamente como parte de la sesión de escritorio”. A partir de este lanzamiento el nombre del host (hostname) puede ser establecido en el momento del arranque con la opción del kernel ‘systemd.hostname=’ y hay nuevas opciones para la línea de comandos del kernel como ‘systemd.swap=’ para alternar en caso de que la SWAP esté habilitada y ‘systemd.clock-usec=’ para especificar el tiempo de Unix en el arranque.

systemd-networkd ha recibido algunas mejoras, al igual que systemd-resolved, que ahora tiene validación de SNI para el soporte de DNS-over-TLS. Para terminar, otras novedades destacadas son la posibilidad de avisar de los procesos que quedan en una unidad después de que esa unidad se haya detenido, soporte básico para el congelador de cgroup v2 y PID1 puede cargar automáticamente las políticas de AppArmor precompiladas durante el arranque temprano.

El init suele ser un componente un tanto ajeno para el usuario común, que lo ve simplemente como un medio para hacer funcionar el sistema operativo. Así que la llegada de systemd 246 no es algo que importe a la mayoría, salvo ciertos usuarios avanzados, administradores de sistema y a aquellos con “versionitis”. Ya se sabe, una rolling como Arch Linux es la vía más sencilla para hacer uso de él si no se quiere pasar por el tortuoso proceso de la compilación.

Fuente: www.muylinux.com

Linus Torvalds sigue siendo el desarrollador que más contribuye con Linux

Linus Torvalds ya no se considera un programador. Así lo manifestaba a finales de 2019, pero lo cierto es que sigue siendo en principal contribuidor del kernel Linux, cuando hablamos de personas físicas.

Según recogían en Phoronix hace un par de semanas como repaso del año, el kernel Linux entra en 2020 con 27,8 millones de líneas de código, lo que supone un aumento de 1,7 millones de líneas a lo largo de 2019. Las estadísticas de Git, sin embargo, arrojan una considerable menor cantidad de commits que en 2018, de aproximadamente 80 000 a aproximadamente 75 000.

Lo curioso del caso es que el creador de Linux, por más que no se considere a sí mismo como un desarrollador, sino como un controlador, sigue siendo la persona individual que más aporta. Así, de los 1,7 millones de líneas de código que se añadieron al kernel en 2019, Torvalds es el responsable del 3,19%. Los siguientes en la lista son David Miller de Red Hat y Chris Wilson de Intel, y así hasta los 4 189 contribuidores que se mantienen en activo.

El grueso del código que llega, no obstante, no se distingue tanto por personas como por organizaciones, de nuevo con Red Hat e Intel a la cabeza, pero en orden inverso en este caso, con -según indican las estadísticas- una amplia mayoría de desarrolladores contribuyendo directamente con su cuenta de Gmail, por lo que se pierde un poco del origen corporativo de dichas contribuciones.

Otro elemento destacado en las estadísticas que comparte Phoronix es el polémico systemd, de novedad reciente por la decisión de Debian de dar un poco de manga ancha en cuanto a la elección de init. Lo cual no significa nada en concreto, pues systemd se mantiene como el sistema de inicio de facto de GNU/Linux… y así seguirán siendo, le pese a quien le pese.

La polémica en torno a systemd, ya lo sabéis, viene a razón de que no es un simple sistema de incio, sino que abarca mucho más de la que deberían ser sus competencia; pero no parece que vayan a cambiar las cosas a este respecto. De hecho, los máximos responsables del kernel están satisfechos con la solución y lo mismo podría decirse de las grandes distribuciones Linux con la excepción de Ubuntu, que traga porque no le queda otra.

La evolución en magnitud de systemd también ha sido destacada a lo largo del año pasado y el proyecto entra en 2020 acercándose a los 1,3 millones de líneas de código, pero con Lennart Poettering, su autor, en segunda posición por número de contribuciones. Hace ya cinco años que lo advertimos: será systemd o la jungla, así que más vale ir haciéndose a la idea de que llegó para quedarse.

Fuente: www.muylinux.com

Debian 8 Jessie, un sistema operativo muy prometedor

logo_debian

Tengo que reconocer que Debian 8 Jessie me parece una versión bastante prometedora. Le di una oportunidad en mi netbook, el mismo ordenador que utilicé para realizar ciertas pruebas superficiales a Fedora 21 Workstation, obteniendo un buen sabor de boca entonces.

Antes de instalar Debian, mi netbook utilizaba Ubuntu con Unity, que se mostraba demasiado pesado, y con tan solo tener Firefox y Google Chrome abiertos a la vez la experiencia de usuario caía en picado, así que decidí darle una oportunidad a Debian 8 Jessie, pero cambiando GNOME por XFCE para ahorrar recursos y así prescindir de la aceleración 3D tan requerida por los entornos pesados, GNOME 3 y KDE.

Aspecto

¿Cómo lucirá el próximo gran lanzamiento de Debian?, pues abajo os dejo algunos pantallazos sobre cómo quedará, porque en su actual estado será complicado ver algún cambio radical.

Al usar Debian un software algo más anticuado que otras distribuciones con el fin de garantizar la estabilidad, el usuario no va a encontrar detalles que le sorprendan. Aquí podéis ver XFCE 4.10, GNOME Shell 3.14.1 y KDE 4.14.2. Honestamente, el wallpaper de Debian Jessie luce en mi opinión peor que el de la versión anterior, mucho más elegante, además que KDE muestra un aspecto un poco cutre y encima no instala por defecto los paquetes de traducción (he instalado varias veces la versión netinst sobre una máquina virtual VirtualBox).

Como-se-ve-por-defecto-Debian-8-Jessie-con-XFCE Debian-8-Jessie-con-GNOME-Shell-1

Debian-8-Jessie-con-GNOME-Shell-2 Debian-8-Jessie-con-KDE

Debian sigue siendo Debian

La principal novedad de Debian 8 Jessie es, como no, el más que polémico systemd. El init de Freedesktop.org e impulsado sobre todo por Red Hat ha sido el protagonista de uno de los debates más agrios que se recuerdan en el mundo de GNU/Linux. Meses después de decantarse por systemd, unos desarrolladores que no estaban de acuerdo pusieron sobre la mesa una Resolución General, a través de la cual querían convertir Debian en una distribución “agnóstica” a nivel de init, con la posibilidad de implementar systemd, Upstart o el que el usuario quisiese. El debate se volvió bastante duro, con dimisiones por parte de muchas personas, tanto a favor de la Resolución General como en contra. Después de volver rojo el agua del mar, se decidió tumbar la Resolución General y systemd se consolidó, provocando el nacimiento de una bifurcación por parte de aquellos que estaban en contra de systemd, Devuan.

¿Qué resultado ha traído esta decisión?, ¿se ha convertido Debian en una aberración transgénica repleta de cosas de Red Hat pero usando paquetes Deb y APT? Quizá los sysadmins más experimentados vean un ogro en systemd, sin embargo un usuario avanzado no notará un salto tan brusco como el que muchos podrían imaginar. Si, Debian por suerte sigue siendo Debian y mantiene buena parte de sus virtudes y característicascon el salto a systemd, no se ha convertido ni por asomo en un híbrido con Red Hat. Los usuarios más básicos de la distribución notarán sobre todo que el manejo de los servicios es diferente, cambiando toda la sintaxis de los comandos. Obvio, se trata de systemd y aquellos que ya lo hayan manejado no verán nada extraordinario, ni que no conozcan, aunque quizá se sorprendan al ver que los servicios siguen iniciándose por defecto junto al sistema después de ser instalados, una característica que yo solo he visto en las distribuciones basadas en Debian (si no me falla la memoria).

Luego la configuración de los servicios no ha cambiado mucho, siguiendo la base de versiones anteriores y que también está presente en Ubuntu. Apache 2 sigue teniendo sus directorios de configuraciones y dominios virtuales disponibles y activos, y VSFTPD sigue teniendo un simple fichero dentro de la subcarpeta /etc, mientras que en otras distribuciones como las basadas en Red Hat (¿o tendría que decirse Fedora?) este demonio de FTP tiene su propia subcarpeta. En resumidas cuentas, los servicios han cambiado en la forma en que se activan, pero no en la forma en que se configuran.

Se que estoy mezclando cosas que no tienen que ver con systemd, pero solo quería mostrar que el usuario no encontrará nada de Red Hat en Debian, o al menos nada que no sea un componente muy básico del sistema que posiblemente esté desarrollado por la empresa estadounidense.

Configuracion-de-Apache-2-en-Debian-8-Jessie VSFTPD-sigue-en-el-directorio-etc-despues-de-que-Debian-haya-migrado-a-systemd

Por otro lado systemd no solo cambia la forma en que se activan los servicios, también tiene otras virtudes, como el dar cierta homogeneización a un sistema operativo que siempre ha sido una mezcla de proyectos un tanto inconexos, además de mejorar de forma más que palpable el tiempo de arranque y apagado del sistema operativo, siendo esta última operación prácticamente instantánea en mi netbook.

Systemd le ha sentado de maravilla a Debian, que por fin ha jubilado un init anticuado como lo es sysvinit. Aparte de aportar claras mejoras al sistema operativo que nos ocupa, y con una excelente implementación por lo que he podido ver, systemd se muestra como un excelente estándar para GNU/Linux.

Las redes son otro punto a tener en cuenta, porque Debian conserva el mismo esquema a la hora de nombrar las redes, manteniendo los famosos wlan y eth, frente a la más reciente que han adoptado las distribuciones basadas en SUSE, Red Hat y Arch Linux, que se basa en el bus PCI.

Redes-en-Debian-8-Jessie

Compatible con software reciente y moderno… por ahora

Debian 8 Jessie se muestra por ahora bastante compatible con software más o menos moderno. También se puede tirar de las versiones para Debian 7, como es mi caso con Megasync.

En la galería de abajo se puede apreciar que he instalado Steam y he podido arrancar el Half Life original, el único juego que puedo ejecutar sobre mi pobre netbook. Esto tampoco es que sea un gran logro por parte de Debian, ya que también he conseguido arrancar Half Life sobre Ubuntu 14.04. Otro software moderno que he podido instalar ha sido Vivaldi, el prometedor navegador que quiere recuperar la esencia del viejo Opera con Presto. Con esto se puede concluir que de momento Debian 8 Jessie abre las puertas a buena parte del software reciente disponible para GNU/Linux.

MuyLinux-en-Vivaldi  Megasync-Steam-y-Half-Life

Sigue mostrándose como un sistema optimizado

Una de las características que más me han gustado de Debian es su optimizado software. Da gusto ver cómo un sistema completo construido sobre él acapara bastantes menos recursos que otros que incorporan lo último, como su “hijo” Ubuntu u openSUSE.

Sin embargo se nota que ya no estamos en la época de Debian 6, cuando este sistema operativo consumía 100 megas recién arrancado con GNOME 2 sobre el Pentium IV que gastaba entonces. Pese a todo los números de Debian 8 Jessie en este sentido siguen siendo bastante buenos, consumiendo unos 130 megabytes recién arrancado sobre mi netbook, y poco más de 30 megabytes en mi servidor virtual.

Debian-8-Jessie-recently-booted Debian-8-Jessie-recien-arrancado-como-servidor

No todo es oro lo que reluce

Debian 8 Jessie es posiblemente el lanzamiento más prometedor de 2015 en lo que a GNU/Linux se refiere, aun así no he podido evitar dos errores que espero que sean corregidos en el futuro.

El primero aparece cuando quito el sonido a través de la tecla Fn, que luego no se restablece al repetir la operación. Para ello tengo que ir a Control de Volumen de PulseAudio (paquete pavucontrol) y deseleccionar la opción de silenciar en Dispositivos de Salida.

Control-de-Volumen-de-PulseAudio-en-Debian-8-Jessie

Otro error, aunque este se manifiesta muy de vez en cuando, es que el proceso de apagado del ordenador se bloquea. La pantalla se queda en negro con un prompt en la parte superior izquierda de la pantalla, sin permitirme realizar ninguna acción, y teniendo que recurrir al “botonazo” para apagar.

Pese a todo no hay que olvidar que Debian 8 Jessie aun es Release Candidate.

Conclusión

Debian 8 Jessie es un sistema operativo que sigue en buena medida todo lo que ha sido Debian hasta ahora, con un gran cambio que para muchos supondrá su “divorcio” de la distribución, systemd, que en mi humilde opinión ha aportado un toque de modernidad y ciertas mejoras que se estaban pidiendo desde hace tiempo.

Fuente: www.muylinux.com

Surge Devuan, fork de Debian sin systemd

devuan

Tal y como parecía que iba suceder ha sucedido, sin redundancia que valga, y la apuesta de Debian con systemd se salda, por el momento y entre otras cosas, con Devuan -pronunciado como DevOne en inglés-, un fork promovido y organizado por administradores veteranos del “sistema operativo universal”.

No hay más novedades aparte del anuncio, pues lo único a lo que aspira Devuan es a ofrecer Debian sin systemd. Así, el primer objetivo del proyecto es generar una base fiable y minimalista de la distribución que debería estar lista para el lanzamiento de Debian 8.

“A día de hoy, las únicas que se resisten (a systemd) son Slackware y Gentoo, pero también tenemos que proporcionar una base sólida para las distribuciones basadas en APT”, indican. “Todos los proyectos basados en Debian que estén preocupados por la avalancha de systemd son bienvenidos a echar un ojo en nuestra iniciativa y evaluarla como una alternativa” prosiguen.

Así que de lo que trata Devuan no es de hacer un fork de Debian de arriba abajo, sino de construir un sistema base libre de ataduras con el ojo único de Sauron en que se ha convertido el sistema de inicio desarrollado por Red Hat, que ya ha provocado un fork del propio systemd, abandonos entre desarrolladores de Debian -la mayoría, parece, van a acabar en Devuan- y bastantes malos rollos en general, especialmente en el seno de Debian.

Habrá que ver si esta alternativa prospera y si se le suman partes interesadas de peso. ¿Se atreverá Ubuntu llegado el caso? Demasiado crudo está todo como para planteárselo. Lo cierto es, unos por seguir la filosofía Unix de “haz solo una cosa, pero hazla bien”, otros por defender la libertad de elección que caracteriza al software libre, a esta historia le quedan muchos capítulos.

Fuente: www.muyliux.com

Debian se queda con systemd, ¿de forma definitiva?

Debian-con-systemd2

Hace un mes os comunicábamos que había luchas internas en Debian, y es que a pesar de que se había decidido reemplazar sysvinit por systemd, parece que muchos no querían aceptar el resultado, empezando una disputa que desembocó en una Resolución General por parte de Ian Jackson, uno de los pesos pesados dentro del Proyecto Debian. Dicha Resolución General, que iba acompañada de una votación, pretendía hacer que Debian no estuviese atado a ningún init en particular, dando la posibilidad al usuario de elegir el que vea más conveniente. Esto fue aplaudido por muchos, pero no todo el mundo compartía esa postura.

Resolución General

Se presentaron varias enmiendas a la Resolución General, que proponían diversas alternativas a lo expuesto por Ian Jackson, que en resumen decían lo siguiente:

  • La primera, presentada por Lucas Nussbaum, planteó el dar soporte a los sistemas de inicio alternativos como una recomendación, no como algo obligatorio. Expuso que si el init por defecto flaqueaba sobre alguna arquitectura, se pudiese cambiar por otro alternativo. Además propuso que todo el software que actualmente se ejecuta sobre sysvinit en Wheezy debería de seguir así para Jessie, en caso de ser técnicamente viable.
  • La segunda, presentada por Luca Falavigna, puso sobre la mesa que los paquetes podrían requerir algún init específico ejecutado como PID 1 si los mantenedores así lo decidían, diciendo que laResolución General cumplía con el contrato social de Debian, de tal manera que se reconocían las decisiones tanto de los desarrolladores upstream como de los mantenedores de paquetes para ofrecer el mejor Software Libre a sus usuarios. Además dijo que no existen parches y otros trabajos con el fin de soportar otros init alternativos para hacer el software utilizable al mismo nivel.
  • La tercera, presentada por Charles Plessy, parece que ha atacado más el procedimiento en sí que la cuestión técnica, diciendo que “el proyecto Debian pide a sus miembros ser considerados cuando se propongan Resoluciones Generales, ya que el proceso de Resolución General puede ser perjudicial, independientemente del resultado”. También se hicieron valer los procedimientos de toma de decisión y resolución de conflictos, diciendo que la Resolución General presentada “no es requerida”. Curiosamente esta enmienda fue apoyada por el dimitido Joey Hess.

Algo más de mil miembros de la comunidad de Debian tenían derecho a votar en esta Resolución General,ganando la propuesta de la última enmienda por un estrecho margen.

Renuncias de algunos miembros por el proceso de Resolución General

Druante el proceso de Resolución General hubo varias renuncias de algunos miembros experimentados de la comunidad, como Colin Watson y Russ Alberry, siendo el primero empleado de Canonical y que apoyó la incorporación de Upstart como reemplazo de sysvinit hace unos meses, mientras que Alberry apoyó a systemd.

Otro que ha decidido irse del Comité Técnico es la persona que propuso la Resolución General, Ian Jackson. Aceptando con deportividad la derrota, ha dicho que se echa a un lado debido a que considera su presencia como “controvertida” llegado a este punto, aunque recalca que es importante que las personas del Comité Técnico que piensan como él sigan ahí.

Hay más nombres que se han caído, como Tollef Fog Heen, encargado de systemd, pero no vamos a profundizar más sobre los motivos personales de cada uno de los miembros, solo recalcar que el desgaste de la comunidad de Debian por este asunto ha sido grande.

Debian/kFreeBSD, ¿sacrificado por culpa de systemd?

Hace diez días el Proyecto Debian anunciaba que abandonaba su variante con el kernel de FreeBSD, Debian/kFreeBSD, como arquitectura oficial. La noticia saltó en medio del proceso de votación en la Resolución General, así que algunos, como iTware, se preguntan si systemd no ha tenido al menos parte de culpa, ya que dicho sistema de inicio está pensado por y para Linux, siendo su portabilidad a FreeBSD impensable hoy en día.

También hay que tener en cuenta la poca aceptación de esta variante del sistema operativo Debian, mientras que desde la comunidad se hace referencia a la falta de calidad del producto.

Fuente: www.muylinux.com

Se promueve boicot contra systemd

systemd

¿Creías que Canonical claudicando ante systemd por Debian era la última polémica que le quedaba por pasar al que está llamado a ser el nuevo sistema de inicio estándar de GNU/Linux? Estabas equivocado. No solo las críticas continúan: se ha organizado un movimiento de boicot en contra del desarrollo de Red Hat.

Antes de seguir y por si alguien se pierde con el embrollo técnico, el sistema de inicio viene a ser el primer proceso que se ejecuta en el arranque del sistema tras la carga del kernel, y se encarga de gestionar el resto de procesos hasta que el sistema operativo es plenamente funcional. Systemd es mucho más que eso, y se adentra en el sistema en muy diferentes aspectos.

Systemd desató la ira de Mark Shuttleworth cuando el comité técnico de Debian todavía debatía qué opción escoger, aunque como hemos dicho, finalmente tuvo que aceptar el revés. Así, systemd se convertirá casi de facto en el sistema de inicio estándar en GNU/Linux, pues las principales distribuciones -Red Hat, SUSE, Debian, Ubuntu- ya lo utilizan o lo utilizarán en breve.

En todo este tiempo, sin embargo, las críticas en contra de systemd se han ido acumulando, a cada cual más cruda. En las últimas fechas hemos recogido alguna de las más destacadas en nuestro PING de los sábados -por ejemplo, aquí una y aquí otra– y tela marinera el ambiente que hay entre la vieja guardia y la nueva. Como indicaban en InfoWorld unos días atrás, pareciera que hay que tomar bando en la guerra.

Así nace boycottsystemd.org, una iniciativa apadrinada por voces discordantes que llama directamente al boicot contra systemd, y “no porque seamos puristas de sysvinit -el sistema al que viene a reemplazar systemd-”, dicen, sino porque “el nuevo sistema de inicio que necesita Linux en el siglo XXI no es systemd”. Y argumentos para aferrarse a tal posición nunca han faltado, como puedes comprobar en el anterior enlace.

Fuente: www.muylinux.com


Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /home1/uiolibre/public_html/wp-content/plugins/simple-lightbox/includes/class.utilities.php on line 545