Fecha actual Jue Mar 28, 2024 8:59 am

Todos los horarios son UTC - 3 horas




Nuevo tema Responder al tema  [ 7 mensajes ] 
Autor Mensaje
NotaPublicado: Mié Nov 19, 2014 10:32 am 
Administrador
Avatar de Usuario

Registrado: Jue Ago 05, 2010 12:02 pm
Mensajes: 7687
Ubicación: Villa Urquiza, Capital Federal
Vivid Vervet

Imagen


Ubuntu 15.04 ya tiene nombre: Vivid Vervet. Así lo ha comunicado Mark Shuttleworth en su blog, en una nota donde analiza las razones de tan singular decisión. La letra “V” era la señalada y la comunidad de Ubuntu ha propuesto varios nombres hasta que finalmente se ha elegido éste.

Fuente: Blog oficial de Mark Shuttleworth

Código:
http://www.markshuttleworth.com/archives/1425


Todavía no está completamente confirmado el calendario de las fechas de esta nueva versión de Ubuntu que verá la luz en Abril del año próximo. Pero seguramente, la página se confirmará en unos días, y es la siguiente:

Código:
https://wiki.ubuntu.com/VividVervet/ReleaseSchedule

_________________
Imagen
Imagen


Arriba
 Perfil  
 
NotaPublicado: Mié Nov 19, 2014 10:50 am 
Avatar de Usuario

Registrado: Vie Ago 06, 2010 1:22 pm
Mensajes: 1507
Ubicación: República Argentina
No sé por qué pensaba que habían desistido con ponerle nombres :unsure:

_________________
Imagen


Arriba
 Perfil  
 
NotaPublicado: Mié Nov 26, 2014 11:13 am 
Avatar de Usuario

Registrado: Mié Ago 04, 2010 9:07 pm
Mensajes: 1486
Ubicación: Junín (BA - Argentina)
Lástima que se contagiaron de la peste SystemD. :(

_________________
Es chamuyo y humo, a menos que se demuestre lo contrario con evidencia de calidad.
Imagen
Imagen
Imagen


Arriba
 Perfil  
 
NotaPublicado: Mié Nov 26, 2014 11:27 am 
Administrador
Avatar de Usuario

Registrado: Jue Ago 05, 2010 12:02 pm
Mensajes: 7687
Ubicación: Villa Urquiza, Capital Federal
qué tiene de malo systemd? pregunto desde la ignorancia

_________________
Imagen
Imagen


Arriba
 Perfil  
 
NotaPublicado: Mié Nov 26, 2014 4:49 pm 
Avatar de Usuario

Registrado: Mié Ago 04, 2010 9:07 pm
Mensajes: 1486
Ubicación: Junín (BA - Argentina)
Me costó un poco encontrarlo, pero en este artículo está la respuesta a tu pregunta. :P

Código:
http://www.linuxito.com/gnu-linux/nivel-alto/431-por-que-systemd-es-una-mierda


Citar:
SystemD es un reemplazo para el demonio SysVInit utilizado en sistemas GNU/Linux y Unix, originalmente creado por Lennart Poettering de Red Hat. Representa un incremento monumental en la complejidad, una abominable y violenta bofetada en la cara de la filosofía Unix, y su inherente naturaleza dominante y viral lo convierte en una especie de "segundo kernel" desparramándose por todo el ecosistema Linux.

El sitio boycott systemd apunta a servir como una síntesis y llamada de atención para tomar una posición en contra de la proliferación generalizada de SystemD, para detallar por qué es dañino, y para persuadir a los usuarios a que rechacen su uso.

Disclaimer: No somos puristas de SysVInit. Reconocemos la necesidad de un nuevo sistema de inicio en el siglo XXI, pero SystemD no lo es.
La síntesis

1. SystemD va en contra de la filosofía Unix: "haz una cosa y hazla bien", representando una colección compleja de docenas de binarios fuertemente acoplados. Sus responsabilidades exceden groseramente las de un sistema de inicio, a medida que avanza sobre el control de energía, manejo de dispositivos, puntos de montaje, cron, encripción de discos, inetd y API para sockets, syslog, configuración de red, manejo de login y sesiones, readahead, particiones GPT, registro de contenedores, manejo de hostname/locale/tiempo, y demás cosas. Keep it simple, stupid.

2. Los archivos de journal de SystemD (manipulados por journald) son almacenados en un complicado formato binario, y deben ser consultados utilizando journalctl. Esto vuelve a los logs de journal potencialmente corruptibles, pues no tienen transacciones ACID. Seguramente no quieres que esto le suceda a tus syslogs. ¿El consejo de los desarrolladores de SystemD? Ignorar el problema. No, en serio. Ah, y además posee integración con un servidor HTTP embebido (libmicrohttpd). Y se sirven códigos QR a través de libqrencode.

3. El equipo de SystemD es notablemente chovinista y anti-Unix, debido a su abierto desprecio hacia el software no-Linux y la subsecuente incompatibilidad de SystemD con todos los sistemas no-Linux. Debido a que SystemD está muy fuertemente acoplado a la API del kernel Linux, esto provoca que las diferentes versiones de SystemD sean incompatibles entre diferentes versiones del kernel Linux (nota del traductor: esto es terrible). Se trata de una política aislacionista que esencialmente suelda al ecosistema Linux en su propia jaula, y sirve como obstáculo a la portabilidad del software (nota del traductor: una de las más grandes cualidades deseables en toda pieza de software).

4. udev y dbus son dependencias forzosas ç. De hecho, udev se fusionó con SystemD hace tiempo. La integración del administrador de dispositivos que fue alguna vez parte del kernel Linux no es una decisión que deba tomarse a la ligera. Las implicancias políticas de ello son altas, y hace que muchos paquetes que dependen de udev, a su vez dependan de SystemD, mas allá de la existencia de forks, como eudev. A partir de systemd-209 los desarrolladores ahora tienen su propia, no estándar y escasamente documentada API sd-bus que reemplaza mucho del trabajo de libdbus, y disminuye aún más la transparencia.

5. Por defecto, SystemD guarda los core dumps en el journal, en lugar del filesystem. Los core dumps deben ser explícitamente consultados utilizando coredumpctl. Más allá de ir en contra de todo razonamiento, esto además crea complicaciones en entornos multiusuario (buena suerte corriendo gdb sobre el core dump de tu programa si se vuelca en el journal y no tenés acceso root), dado que SystemD requiere acceso root para controlarlo. Asume que usuarios y administradores son tontos por igual, pero más críticamente, la fundamentalmente naturaleza corruptible de los logs de journal lo vuelven un severo impedimento.

6. El tamaño de SystemD lo vuelve un punto simple de fallo. Hasta este artículo, SystemD tiene 9 reportes CVE, desde su concepción en marzo de 2010. Hasta ahora no parece mucho, pero su esencial y prepotente naturaleza lo convertirá en un blanco jugoso par los crackers, ya que es mucho más pequeño que el kernel Linux en sí mismo, pero casi igual de crítico.

7. SystemD es viral por naturaleza. Su alcance en funcionalidad y arrastre como dependencia a cientos de paquetes significa que los mantenedores de distribuciones vana necesitar una conversión, o van a quedar a la deriva. Como ejemplo, GNOME ha adoptado a SystemD como dependencia fuerte desde la versión 3.8 para varias utilidades, incluyendo gdm, gnome-shell y gnome-extra-apps. Esto significa que las versiones de GNOME mayores a la 3.8 son incompatibles con sistemas no Linux, y debido a la popularidad de GNOME, ayudará a inclinar a muchos mantenedores a agregar SystemD. El rápido crecimiento en adopción por parte de distribuciones como Debian, Arch Linux, Ubuntu, Fedora, openSUSE y otras muestra que muchos se subieron al tren, con o sin justificación. Tampoco sirve de nada que SystemD se rehuse a iniciar como una instancia de usuario, a menos que el sistema bootee con él (es una coacción descarada).

8. SystemD se encierra a sí mismo en el PID 1. Debido a que controla gran cantidad de componentes diferentes, significa que hay toneladas de escenarios en los cuales puede crashear y voltear al sistema por completo. Pero además, significa que muchas actualizaciones del sistema (sin tratarse del kernel) van a requerir un reinicio. ¡Que disfrutes tu nuevo sistema Windows 9 Linux! Para ser justo, SystemD provee un mecanismo para reserializarse y reejecutarse a sí mismo en tiempo real. Pero claro, si esto falla, el sistema se cae. Hay muchas formas por las que esto puede ocurrir. Esto es otro ejemplo de SPOF (punto simple de fallo).

9. SystemD fue diseñado con glibc en mente, y no se preocupa mucho por soportar otras libcs. En general, la idea de librería C estándar de los desarrolladores de SystemD es una que sea compatible bug-por-bug con glibc.

10. La naturaleza complicada de SystemD lo vuelve difícil de extender y salir fuera de sus límites. Mientras que es posible mas o menos iniciar scripts de forma trivial con archivos, es más difícil implementar un comportamiento que salga de la caja. Muchos usuarios necesitarán posiblemente escribir programas más complicados que directamente interactúen con la API de SystemD, o directamente necesitarán parchar SystemD. Uno debe preocuparse por una mayor cantidad de caminos de ejecución y comportamiento en un programa crítico del sistema, incluyendo la posibilidad de que SystemD no sincronice bien con la cola de mensajes de dbus en tiempo de boot, congelando el sistema. Esto es opuesto al tradicional init, que es determinístico y predecible por naturaleza, dado que mayormente sólo ejecuta scripts.

11. En última instancia, el parasitismo de SystemD es el símbolo de algo más que SystemD en sí mismo. Muestra un cambio radical de pensamiento en la comunidad Linux. No necesariamente positivo. Sino vehementemente postmoderno, monolítico, fuertemente orientado a sistemas de escritorio, limitante de posibilidades, aislacionista, reinventor de la rueda, y un gran anti-patrón en general. Si tu meta es complacer al más bajo denominador común, que así sea. Nosotros sin embargo buscaremos alternativas.

12. SystemD ni siquiera sabe qué mierda quiere ser. Es referido diversamente como "demonio de sistema" o un "bloque de construcción básico para construir un sistema operativo en espacio usuario", las cuales son definiciones bastante ambiguas. Se deglute funcionalidad que pertenecía anteriormente a util-linux, wireless tools, syslog, y otros proyectos. No tiene una dirección clara más que los caprichos de los desarrolladores. Irónicamente, más allá de que apunta a estandarizar las distribuciones Linux, no tiene un estándar claro en sí mismo, y está perpetuamente liberando versiones.

Este es el artículo (por así llamarle) de mayor claridad, donde se exponen los argumentos de forma concisa con una gran cantidad de enlaces a las fuentes. Recomiendo ampliamente visitar el sitio ya que pueden encontrar gran cantidad de material con argumentos y exposiciones de expertos en contra de SystemD. Algo que me gustaría recalcar respecto a la filosofía Unix, es que más allá de la premisa básica de "haz una cosa y hazla bien", el usar archivos de texto plano es otra de las premisas. Y la justificación es que los archivos de texto planos son el formato de transmisión y almacenamiento de información más altamente portable que existe. Es decir, dejar de usar archivos de texto plano es romper con otra de las premisas de la filosofía Unix.

Algo que no deja de asombrarme, es que SystemD esté tan fuertemente atado a la API del kernel Linux, que llegue al punto de que una versión de SystemD no sea compatible entre diferentes versiones del kernel Linux. Esto refuerza la idea de "segundo kernel".
(Cité una pequeña parte de todo el artículo, hay como tres o cuatro traducciones con más material de lectura)

_________________
Es chamuyo y humo, a menos que se demuestre lo contrario con evidencia de calidad.
Imagen
Imagen
Imagen


Arriba
 Perfil  
 
NotaPublicado: Jue Nov 27, 2014 1:10 am 
Administrador
Avatar de Usuario

Registrado: Jue Ago 05, 2010 12:02 pm
Mensajes: 7687
Ubicación: Villa Urquiza, Capital Federal
Yo quería tu opinión....

_________________
Imagen
Imagen


Arriba
 Perfil  
 
NotaPublicado: Jue Nov 27, 2014 5:45 pm 
Avatar de Usuario

Registrado: Mié Ago 04, 2010 9:07 pm
Mensajes: 1486
Ubicación: Junín (BA - Argentina)
Ah, eso, no entendí bien tu post, perdón. ^_^º

Si bien soy de los que piensan que el cambio hace andar al mundo, es un toque preocupante IMHO lo que están haciendo estos muchachos, pero por todo lo que leí, me parece que el problema no es la existencia misma de SystemD, sino que esté tan viralizado y que se esté extendiendo a muchísimas distros con todos sus problemas encima. (Sin contar lo que esto puede significar para los admins de servers)

_________________
Es chamuyo y humo, a menos que se demuestre lo contrario con evidencia de calidad.
Imagen
Imagen
Imagen


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 7 mensajes ] 

Todos los horarios son UTC - 3 horas


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 29 invitados


No podes abrir nuevos temas en este Foro
No podes responder a temas en este Foro
No podes editar tus mensajes en este Foro
No podes borrar tus mensajes en este Foro

Buscar:
cron
Powered by phpBB® Forum Software © phpBB Group
Traducción al Español Argentino por nextgen
en colaboración con phpBB España
[ Time : 0.029s | 19 Queries | GZIP : On | Load : 0.37 ]