#149 ¿por qué la importancia la da solo la visibilidad? Porque lo dice @peligrogitano, ¿no? Para mí hay cosas más importantes.
Vaya tonterías que dices. Para empezar, el sistema de paquetería es RPM. Yum es solo un software de gestión por encima. Y yo no he dicho que lo utilice todo el mundo, solo he dicho que es una aportación. De hecho se considera RPM el sistema de paquetería estándar de GNU/Linux según tengo entendido. Y lo de que Kickstart no vale para nada... En fin, sin comentarios.
Y lo de insinuar que Red Hat no aporta nada... ¿Sabes que Red Hat está entre las empresas que más aporta en el código de Linux? Deberías informarte antes de hacer el ridículo diciendo esas cosas.
La verdad, no sé por qué en este tema escribís tanto gente que tenéis tan poca idea. Es casi un misterio. Todo el mundo se cree que sabe mucho.
#56 No, eso es lo que es, sino mira cualquier log de un contenedor que levantes con LXD y verás un montón de referencias a archivos C que son todos los que gestionan el contenedor a bajo nivel (creación, arranque, ...), y no son de LXD son de LXC.
Ejemplo que ves en cualquier log, este es de un contenedor que acabo de levantar ahora mismo con LXD: "lxc_commands - commands.c:lxc_cmd_get_state:579 - 'sheenless-nguyet' is in 'RUNNING' state"
Y eso lo puedes hacer exactamente igual para cualquier log del contenedor, o te crees que es LXC más que nada porque LXD, a diferencia de LXC, no tiene ni una línea de C, aparte de que no tiene mucho sentido picarse algo como un contenedor en Go.
Así que sí, LXD es básicamente un sistema de gestión de contenedores con una interfaz REST que tira de los bindings en Go de LXC (github.com/lxc/go-lxc) para ejecutar las operaciones sobre los contenedores.
#145 para empezar, el hecho de que en una plataforma haya más usuarios directos no quiere decir que sea más importante. Sin servidores no habría Internet y todo el mundo los utiliza, solo que de forma indirecta. No creo que el segmento del escritorio tenga que estar por encima.
Por otro lado, aun suponiendo que fuera así, es que Canonical solo ha conseguido menos del 1% de la cuota de mercado. Poner eso por encima de lo conseguido en el mercado de los servidores me parece injusto.
Lo que dices de Red Hat ya es más grave. Creo que no sabes bien de lo que hablas. Red Hat colabora mucho más con código en GNU/Linux que Canonical y ha hecho enormes aportaciones, todas libres, como su sistema de paquetería, Kickstart, etc. Es un hecho que Red Hat ha dado más líneas de código a la "comunidad" que Canonical. Por favor, no patinemos.
Stallman y Torvalds han hecho que empresas como Canonical o Red Hat, sencillamente, puedan existir. Si no fuera por GNU, Linux o GNOME, Canonical no podría empaquetar nada. Los que desarrollan son más importantes que los que empaquetan.
Dicho todo esto, insisto en que Canonical tiene mérito, pero no hay que exagerar.
Para empezar, WSL no es una solución "más elegante a WINE", el núcleo de WINE hace exactamente lo mismo, si han decidido reimplementar las API de Microsoft es para que no tengas que instalarte un Windows con sus requisitos de licencia (como aquí tienes que instalar un Ubuntu si quieres ejecutar sus aplicaciones).
Podrías, de igual manera, instalar las librería y entorno de Windows sobre WINE.
Por otra parte, toda traducción implica un sobrecoste, que este sea pequeño o despreciable, como es el caso de las llamadas al sistema, no implica que no lo haya. Hay un proxy entre las llamadas de Linux y las de Windows por tanto cada una añadirá mínimo una decena de operaciones aritméticas (incrementar pila, mover variables, saltos de ejecución...) eso suponiendo que haya una traducción directa y no haya que hacer traducciones, claro. Aún así, es despreciable como en el caso de WINE.
Además, al lanzar el ejecutable deben reemplazarse las referencias, ya sea antes de cargar la imagen a memoria o mediante un hook que las capture cuando se va a hacer la llamada. Eso también lleva una carga.
Hoy en día la sobrecarga de una MV es muy reducida, casi despreciable también. Desde que la CPU tiene soporte nativo se limita prácticamente a emular periféricos. Como mucho el espacio fijo que supone en disco y memoria.
#141 vamos a ver, distingamos. Decir que el trabajo de Canonical ha sido bueno en muchos aspectos (en otros no) es correcto, decir que sin Canonical GNU/Linux en el escritorio estaría mucho peor de lo que está es correcto, pero decir que ha hecho más que Linus Torvalds, por ejemplo, es un columpiamiento con triple tirabuzón.
El mérito de Canonical, que no es poco, ha sido hacer llegar GNU/Linux a mucha gente sin conocimientos de Informática y es una empresa que, en el escritorio, donde la cuota de usuarios de GNU/Linux (ni siquiera de Ubuntu) está entorno al 1%, está teniendo un papel importante. Punto. Solo Red Hat, por ejemplo, colabora muchísimo más que Canonical con el desarrollo de GNU/Linux y tiene una cuota de mercado en su segmento a años-luz de Canonical en el suyo. Sin quitar mérito a Canonical, creo que Red Hat tiene más mérito, por ejemplo, y no digamos Torvalds o Stallman con sus respectivas organizaciones.
#23 los que más hacen por GNU/Linux son los que hacen el código (además, desde hace muchos más años que Canonical), no los que lo empaquetan y los que más han hecho son los que han conseguido que esté en la inmensa mayoría de los servidores, no los que han conseguido que esté en el 1% de las máquinas de escritorio. No le quito mérito a Canonical, pero no nos columpiemos, por favor. Si no fuera por la Linux Foundation y la FSF ni siquiera existiría Canonical.
#127 ¿Existe alguna teoría, justificación o explicación para lo de "sin manos"? Solo se me ocurre que sea una alegoría al "sin cerebro" cuando se pusieron a escribir el guión
#191 Pero es que la "raza" de lidia es producto de cruces y cruces con el único fin de mejorar sus condiciones para el toreo. Desconozco su producción de leche y carne pero probablemente esté muy lejos de las demás razas que se han ido seleccionando para eso y no para torearlas. #109 te lo explica mejor.
#23 joder se me saltan las lagrimas leyendote, años llevo peleando con los talibanes de linux, sobre hacer linux asequible y facil de usar para la gente comun.
#78 LXDE. Feo cómo un dolor, pero rápido como Usain Bolt. Si te tiras 10 horas al día delante de un PC, esos milisegundos de animaciones y cosas bonitas, se convierten en minutos, y los minutos en horas.
#23 Ubuntu ha conseguido ser más fácil para el usuario básico que Windows. 10 no será una puta mierda, pero ha conseguido ser más difícil que Windows anteriores (aunque eso viene del .
#31 No hace falta ni salirse del titular, a ver si lo pillas: "Ya se puede correr Ubuntu con Unity en <UN SISTEMA OPERATIVO DE ESCRITORIO> de forma nativa"
Y te repito que yo sí estoy hablando de lo que se trata: el uso que le voy a dar o no, yo particularmente, en un entorno de escritorio Windows, que es de lo que sí trata el artículo.
Deja de hacerte pajas mentales, no sé si es que lo haces por trolear o realmente no sabes de qué estás hablando realmente, "Winkyface".
#39 LXC y LXD no son software distintos. LXD depende de LXC para la gestión de contenedores local, lo que añade es funcionalidades extras encima de esta como la gestión remota a través de REST y la orquestración de contenedores.
Y tampoco es que sea el único que está haciendo algo similar, está RedHat con Project Atomic por ejemplo, aunque este a diferencia de LXD que puedes hacerlo funcionar en cualquier Linux que soporte un LXC relativamente moderno, hasta donde yo sé solo funciona en RedHat y derivados.
. 
Vaya tonterías que dices. Para empezar, el sistema de paquetería es RPM. Yum es solo un software de gestión por encima. Y yo no he dicho que lo utilice todo el mundo, solo he dicho que es una aportación. De hecho se considera RPM el sistema de paquetería estándar de GNU/Linux según tengo entendido. Y lo de que Kickstart no vale para nada...
Y lo de insinuar que Red Hat no aporta nada...
La verdad, no sé por qué en este tema escribís tanto gente que tenéis tan poca idea. Es casi un misterio. Todo el mundo se cree que sabe mucho.