no sean absolutos al pensar que todos poseen aunque sea navegacion nacional porque en la realidad no es asi, muy bien por Lazaro al enviarlo a la lista.

On 04/12/14 14:56, Ludwig Causilla wrote:
Todos los que tengan acceso a GUTL (el portal cubano) y a DesdeAbreus.cubava.cu van a tener acceso al articulo.
El 04/12/14 15:40, låzaro escribió:
tu y cuantos más sin acceso a internet crees que lo hallan visto?


Thread name: "Re: [Gutl-l] Fw: Desmitificando SystemD [Desde Linux]"
Mail number: 2
Date: Thu, Dec 04, 2014
In reply to: Ludwig Causilla
Hasta por la lista de soporte salio mi modesto articulo.... Lázaro
el articulo está en DesdeLinux pero anteriormente salio de mi Blog
personal e incluso lu publiqué en GUTL  ¿No crees que ya son
bastantes espacios?


El 04/12/14 15:11, låzaro escribió:
----- Forwarded message from feedblas...@hcg.sld.cu -----

Date: Wed, 03 Dec 2014 21:49:55 -0500
From: feedblaster@localhost
To: lazaro@localhost
Subject: Desmitificando SystemD [Desde Linux]
X-Mailer: feedblaster.rb - ruby 2.1.4p265 (2014-10-27 revision 48166) [i686-linux]

Desmitificando SystemD

Cada día nuestros ordenadores forman una parte más importante de nuestra vida, si tiene algún tipo de problema nos afecta nuestro estado de ánimo, nuestro humor jeje. Claro, los usuarios de Windows son más propensos a ataques de pánico, que si los virus (viva linux!), que si desfragmentar el HDD, que si buscar e instalarse el Clean Master para PC (aunque aquí en Linux igual debemos
limpiar el sistema, BleachBit es una de las alternativas preferidas).
Recientemente los usuarios de Linux tenemos (algunos) cierto dolor de cabeza
llamado: systemd

Bueno al grano, he leído un artículo interesante sobre systemd, que parece ser
lo que está de moda desde hace no mucho.

SystemD, que a algunos le parece como (y haré uso de palabras de un amigo), one ring to rule them all ... a otros simplemente ni les va ni le viene, mientras el ordenador funcione bien, no le importa si init hace X o Y cosa, o si se usa systemd. A este quien les escribe, bueno... digamos que prefiero init, lo
encuentro más simple :)

Les dejo aquí el artículo:

Antes de comenzar debo decir que no me gusta nada la decisión de cambiar las cosas en Debian pero, en ningun momento planeo abandonar mi querida espiral. Solo intento que, si vamos a discutir un tema, por lo menos lo hagamos lo más preparados posible aún cuando yo mismo no me considero pro-systemd. Para lograr
la desmitificación de systemd me apoyaré en un sitio web donde los
desarrolladores dan su punto de vista el cual llegó a mis manos por un colega que si parece ser pro-systemd aunque no sea usuario de Debian. Dicho esto creo
que puedo pasar a intentar desmitificar lo que se dice sobre systemd.

systemd es a base de binarios

Quizás este sea uno de los aspectos que más nos choquen, ¿si todo es a base de binario como monitorear las cosas que usualmente hacemos a través de logs?. No tengo ni idea de como nació este mito, pero no es absolutamente cierto.

systemd se configura casi exclusivamente a través de archivos de texto simple. Unos ajustes que también pueden alterar con la línea de comandos del kernel y a través de variables de entorno. No hay nada binario en su configuración (ni siquiera XML). Sólo un simple, sencillo y fácil de leer archivo de texto.

systemd hincha homero simpson

Esa cosa es monolítica y lo controla todo

Antes de llegar a la web mencionada anteriormente confieso que yo mismo pensaba de esta manera pero luego de leer lo que dicen sus desarrolladores mi opinión
ha cambiado algo...

Si usted hace una build de systemd con todas las opciones de configuración habilitadas usted construirá 69 binarios individuales. Estos binarios sirven para diferentes tareas, y se separan cuidadosamente por un número de razones. Por ejemplo, se ha diseñado systemd pensando en la seguridad, por lo tanto, la
mayoría de los demonios corren con privilegios mínimos (utilizando las
capacidades del núcleo, por ejemplo) y son responsables de sólo tareas muy específicas, para reducir al mínimo su superficie la seguridad y el impacto. También, systemd paraleliza el arranque más que cualquier solución anterior. Esta "paralelización" se crea ejecutando varios procesos en paralelo. Por lo tanto queda visto que systemd está muy bien dividido en muchos binarios y por lo tanto los procesos. De hecho, muchos de estos binariosse separan tan bien,
que son muy útiles fuera de systemd.

Un paquete que incluyó 69 binarios individuales difícilmente pudiera ser llamado monolítico. Lo que es diferente de las soluciones anteriores sin embargo, es que enviamos más componentes en un único tarball, y los mantenemos encadenados en un único repositorio con un ciclo de lanzamiento unificado.

Eso no se parece a Unix

Ciertamente hay algo de verdad en eso. Los archivos de las fuentes de systemd no contienen una sola línea de código procedente de las líneas originales de UNIX. Sin embargo, se deriva la inspiración de UNIX, y por lo tanto hay un montón de UNIX en systemd. Un ejemplo sería la idea de UNIX "todo es un archivo" el cual se encuentra reflejado en que en systemd todos los servicios se exponen en tiempo de ejecución en un sistema de archivos del kernel, los cgroupfs. Entonces, una de las características originales de UNIX fue el soporte multi-seat, basada en el apoyo integrado en el terminal. Con systemd trajimos el soporte multi-seat de forma nativa nuevamnte, pero esta vez con el soporte total para el hardware de hoy, que cubren gráficos, ratones, audio, cámaras web y más. De hecho el diseño de systemd como una suite de herramientas integradas que cada uno tiene sus propósitos individuales pero cuando se usan juntos son más que la suma de las partes, que más o menos en el centro de la filosofía UNIX. Entonces, la forma en que nuestro proyecto se maneja (es decir, el mantenimiento de la mayor parte del núcleo del sistema operativo en un único repositorio git) es mucho más cercano al modelo BSD (que es un verdadero UNIX, a diferencia de Linux) de hacer las cosas (donde la mayor parte del sistema operativo central es mantenerse en un único repositorio CVS / SVN) cosa que
nunca fue asi en Linux.

En última instancia, la cuestión de si algo es UNIX o no importa muy poco. Siendo técnicamente excelente es apenas exclusivo de UNIX. Para nosotros, UNIX es una influencia importante (de hecho, el más grande), pero también tenemos otras influencias. De ahí que en algunas zonas systemd serán muy UNIX, y en
otras un poco menos.

Es que eso es muy complejo...

Ciertamente hay algo de verdad en eso. Las computadoras modernas son bestias complejas y el sistema operativo que se ejecuta en ellas obviamente también lo será, por lo tanto tienen que ser complejo. Sin embargo, systemd ciertamente no es más complejo que las implementaciones anteriores de los mismos componentes. Es más sencillo, y tiene menos redundancia. Por otra parte, la construcción de un sistema operativo sencillo basado en systemd implicará mucho menos paquetes que los que usa un Linux tradicional. Menos paquetes hace que sea más fácil de construir su sistema, se deshace de las interdependencias y de gran parte del
comportamiento diferente de todos los componentes involucrados.

Eso no me va a dejar usar scripts de Shell

Esto es totalmente falso. Simplemente no los usamos para el proceso de
arranque, porque creemos que no son la mejor herramienta para ese propósito específico, pero eso no significa systemd era incompatible con ellos. Puede ejecutar fácilmente los scripts de shell como servicios systemd o demonios, puede ejecutar scripts escritos en cualquier idioma como servicios systemd ya que a systemd no le importa lo más mínimo lo que hay dentro de su ejecutable. Por otra parte, en gran medida utilizamos scripts de shell para nuestros propios fines, para la instalación, construcción, pruebas de systemd. Y usted puede pegar los scripts en el proceso de inicio temprano, se utilicen para los servicios normales, se pueden ejecutar en la última parada, prácticamente no
hay límites.

Llegados a este punto supongo que algunas de las principales creencias pueden haber sido aclaradas, a pesar de no sentirme un defensor del cambio y tener mis recelos sobre eso de "un demonio para controlarlos a todos" creo que al final nadie se atreverá a decir que por lo menos no funciona, incluso conozco algunos usuarios que notan que con systemd "la PC camina mas rapido" pero ya esas serían otras cosas que pudieran discutirse. Por el momento solo me resta invitarlos a debatir aquí los puntos de vista que tengan sobre el gestor de
inicio que muchas distribuciones han adoptado aunque ahora las mayores
reacciones se estén viendo dentro de la comunidad de Debian el cual hasta le ha nacido un nuevo fork con todo esto. Si gustarle o no es una cuestion de cada
uno, yo por mi parte solo quiero poner mi granito de arena en la
desmitificación de systemd que al final va a estar presente en Jessie, la
próxima versión estable de Debian.

  El artículo lo ví en GUTL (que a su vez fue tomado de DesdeAbreus)

poettering-1984

¿Actualidad de systemd?

Soy de los que no lee muchas noticias cuando algo genera tanta polémica, prefiero quedarme con detalles más técnicos. Es que.... a veces siento que determinados temas dejan de ser una discusión o debate meramente técnico, y
pasan a ser como uno de esos chismes de farándula :(

Primero una bronca abierta de un usuario a systemd llamada systemd VS
inteligencia, luego Linus Torvalds diciendo que systemd no es tan malo como lo pintan (y algo de razón si que tiene), un fork llamado uselessd ... no comments ...
y para no alargar más, finalmente Devuan.

No diré si es tan malo como dicen, menos malo o peor. A mí el sistema me funciona sin problemas, no obstante por gusto personal preferiría init, pues su forma de organizar varias cosas (como logs por ejemplo) me gusta más, pero bueno, si systemd viene a ser llamado un caballo de carreras y debe sustituir a init (¿sería nuestro mulo de carga, que hace todo pero lento?) pues... hombre, mientras el cambio no sea extremadamente brusco, los usuarios se puedan adaptar sin mucho problema y el sistema funcione mejor (sí, mejor, igual no me vale!),
pues bienvenido sea :D

The post Desmitificando SystemD appeared first on Desde Linux.

[UsemosLinu] [UsemosLinu] [UsemosLinu] [UsemosLinu] [UsemosLinu]
*

----- End forwarded message -----



______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
--
Ludwig Causilla Leyva
Ing. en Ciencias Informáticas.
Administrador de Red en JCCE Abreus
telefonos 540 348


________________________________________________________________
XII Edicion del Evento Nacional de Informatica para Jovenes. INFOCLUB.
Abril. 2015. Ver www.jovenclub.cu
________________________________________________________________
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.jovenclub.cu/pipermail/gutl-l/attachments/20141204/5f07e817/attachment.html>
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
________________________________________________________________
XII Edicion del Evento Nacional de Informatica para Jovenes. INFOCLUB.
Abril. 2015. Ver www.jovenclub.cu
________________________________________________________________


--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.


______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l




--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l

Responder a