Me descargué los otros días la ISO de RHEL7 64 bit (la unica de beta que hay), y la instalé a ver que tal. Le saque algunos screenshot para que la vean, corriendo en VBOX obviamente.
En la primera imagen, se puede apreciar un error, tipico de betas, en la segunda que viene por defecto gnome classic, pero tambien gnome, o sea, no es que viene SOLAMENTE classic, sino que es el que viene por defecto.
Y en la tercera imagen pueden ver el uso de ram, kernel, etc, que lo tire en una sola linea asi podia apreciarse mejor.
Para mi, iba muy lento, e incluso inicia mas lento systemd que mi CentOS 6.5 upstart.... ademas de que la comodidad de upstart al ver el paso a paso del inicio no me la quita nadie, sin contar que ese error de la primera imagen es un obvio pifie de systemd.
Algo notable, es que si le dejamos que cree el esquema de particiones solo, por defecto usa XFS no ext4, asi que... los que usen kernel 3.10 en Fedora, deberian hacer lo mismo, y esto lo digo, porque los parches de XFS que van a parar a RHEL salen de Fedora, y si en RHEL lo usan asi, por algo será.
Sinceramente, me apena que Debian haya optado por systemd para sus proximas versiones, en un servidor uno no anda añadiendo servicios todo el tiempo (lo unico positivo de systemd) y menos reiniciando, asi que lo unico que nos queda a los que buscamos algo simple y robusto es Slackware o Gentoo para servidor?.
Coincido. Yo migre todos mis pc's y servidores de CentOS o Debian a Slackware y anda que no se nota el alivio :D
ResponderEliminarSi, por ahora Debian usa upstart pero ya dijo que para la proxima viene systemd, y por lo tanto canonical lo mismo, los unicos que quedan excentos de esa basofia son Slackware y Gentoo porque hasta ArchLinux lo ha adoptado, de todas formas, a nadie se le ocurre usar Arcn en servidores, bah, a nadie que lo conozca en profundidad
EliminarEs una lastima que un software tan bien cuidado y estable como lo es Red Hat y sus clones dependeran de systemd. Asi como tambien Debian y sus derivados lo haran. Practicamente por su desicion estas dos ramas, que son las mas significativas en Linux, systemd esta ya impuesto por defecto. Aunque Gentoo y Slackware como apuntas no lo utilizaran, mas que nada por su filosofia, caracteristicas y base de usuarios que son muy diferentes. Y Openrc y Upstart hubiesen resultado una mejor opcion para Debian, como oposicion de una rama sobre la otra por un demonio que realmente aporta muchas desventajas y con opciones tan buenas como las anteriores no resulta necesario.
ResponderEliminarEsperemos que nuestras comunidades y desarrolladores piensen mejor las cosas.
Debian deberia haber optado por tener ambos y al momento de instalar decidir cual elegir, si total, systemd es compatible con el estilo viejo de scripts de upstart o sysvinit...
EliminarLo que respecta a RHEL, deberian haber hecho lo mismo, pero era claro que iban a pegar el salto para imponer un standar, algo que les ha dado resultado, solo 2 distros de las conocidas no usan systemd... el resto ahora debe seguir a como vaya systemd y cruzar los dedos... me parece muy penoso, porque ademas, systemd es tan complejo que solo desde upstream pueden cambiarse cosas sin romper nada, cosa que incluso con upstart no era necesario, si algo no te gustaba, editabas los initscripts, era mucho mas modular, pero hay gente que aun defiende a systemd... no se con que base tecnica... con la de "es mas facil crear demonios"?, si es eso... yo les diria que entonces lean un poco mas de bash y aprendan a crear un script para un servicio... es falta de conocimiento no falta de capacidad de upstart.
Para peor de los casos, hay algo, con lo que upstart rompe, que es la regla UNIX y Linux de -todo es un archivo de texto-, haciendo que journald, el reemplazo de syslog, escriba los datos encriptados en formato no estandar y solo puedan leerse desde la misma pc que los escribio. Entonces, si se rompe el OS y debo ver el log, como carajos se supone que lo hare desde un liveCD?....
Tampoco loguea remotamente journald y eso de que todo dependa de systemd... hasta udev se ha reemplazado, lo veo como el culo.
Es el mismo enorme error de regedir que ha cometido y no arregla Windows hace años, todo centralizado en un solo archivo complejo.... pero que va, era de esperar, si vemos a pulseaudio, tambien creado por Lennart, el mismo que hizo systemd... vemos que la base de pulseaudio es Windolera.... asi que no me esperaba otra cagada..
En fin, una real pena, yo por ahora seguire usando CentOS 6.5.... total tengo MUCHOS años mas de soporte, y el dia que no, usaré Slack o Gentoo.
Se comenta que Gnome y KDE van a meter servicios para systemd en sus próximas versiones. Así que va a ser exactamente eso, un nuevo pulseaudio: puede que te guste su programación o no, puede que te de problemas o no (en el 2014 pulseaudio me seguía dando problemas, y Lennart tan pacho), pero los programados insisten en que es lo mejor.
EliminarEspero que por la diversidad, Slackware y Gentoo puedan aguantar sin systemd.
Asi es, en mi realtek ALC888 con protocolo Intel Azalia, en mi desktop, pulseaudio genera esos errores tipicos en messages de pollin nos desperto, tantos eventos suprimidos, cuando abro Skype que usa audio y tengo reproduciendo algo. Lo reporte alla por Fedora 13, el mismo Lennart (cuando no era una estrella estrellada) me respondio diciendo que... (es para morirse): ALSA es mierda y pulseaudio no tiene la culpa de que los driver de Intel Azalia de ALSA sean pesimos, y como pulseaudio usa timer, esa calidad probre se ve reflejada, que anule el timer, pero que NO habia solucion.
EliminarTe imaginaras que al sacar el timer, que esta en la wiki de Arch, es poner tsched=0 mejora, pero no arregla el tema, ahora bien, sabias que con versiones viejas de alsa y pulse, como en ubuntu 7.04 eso no pasa en el mismo hardware?.... se lo comenté a Lennart en el reporte, lo ignoro por completo, porque claro..................................... no es relativo al bug reportado... en fin, tecnicismos que hacen que un bug termine EN NADA por años.
Ahora, si notas, lennart se escudó en que ALSA... si?, lo mismo hizo con systemd, en su blog, 0pointer.de, dice "systemd no tiene la culpa, no maten al mensajero, el problema es udev" o ahora lo de Kay Sievers, que el problema es que debug es generico, deberia ser kernel.debug el valor de cmdline, por eso systemd se confunde, que deben cambiarlo... por eso Torvalds lo mando a cagar y con justa razon, por AÑOS el kernel uso sus parametros y nadie se metia con el, ahora, una falla de systemd se mete con el?, porque no reconocer la falla en vez de exigir cambiar estructuras del kernel que son ASI, la misma mierda hicieron con el famoso UsrMove, que todos, incluso amigos, me mataron al decir que era un espanto para tapar un fallo de systemd... unos años despues salio publicado que asi era, pero en ese momento todos creyeron como idiotas el cuentito de Fedora de que era por motivos SOLAMENTE historicos los de / y /usr (si lo era, pero con el tiempo se dieron cuenta que ADEMAS servia de mucho), bueno, ahi tenes el UsrMove y asi como con el cmdline, sin nadie que les meta un freno, estos chicos buscan hacer lo que les viene en gana, porque ademas, generan dependencia de Red Hat, entre wayland, systemd y KVM (no se si notaste que si bien centos lo usa, RHEL saco Xen), generan dependencia de un producto y lo expanden.
No se hasta que punto no hubo un billetin para Debian al elegir systemd por sobre OpenRC o Upstart, porque todos sabemos que incluso a Debian le genera un ENORME problema, por el kernel BSD y su otra variante con Hurd, en fin.
Slackware va a seguir usando lo que se le canta, porque lo hacen 4 gatos locos que no buscan dinero, nunca lo buscaron, sino frikear un rato y hacer la distro soñada para ellos, por eso tampoco admiten meter cosas buenas y nuevas como un package manager, y Gentoo es una fundacion no lo olvides, que mas o menos tiene el mismo principio, un grupito de hackers usando la distro mas elite de todas luego de LFS, entonces, ellos no van a meter de prepo si o si systemd, en el caso de gentoo podes usarlo, pero no te lo meten de prepo..
En fin que decir, en muchas cosas Red Hat genera y se le agradece,pero, hasta que punto no lo hacen para volverse inprescindibles y asi tener cierta impunidad????? (me refiero a que son los que mas aportan al kernel linux, por algo sera...)
Saludos y la verdad, esto no va a cambiar, asi que o habra que usar systemd o terminar usando slackware/gentoo o LFS, porque como va la cosa.....mal mal veo el futuro de Linux independiente.... muy mal.