Si, leyeron bien y no es poco. Si bien red hat -RHEL- es una distro paga, hay cosas que ... si bien planteadas estan (diria yoda), respondidas serán.
Me animo a decir que incluso, mejor soporte que en Fedora y creo que, por algunas cosas obvias.
1.- Si algo parece ser un bug, lo analizan con MUCHO detalle en RHEL, y en caso de no serlo, su conclusión se vuelca en la respuesta del developer
2.- Existen MUCHOS mas bug por cerrar de Fedora que de RHEL, lo que hace que la gente de RHEL este menos atareada
3.- Es gente un poco... mas seria, no es que sea otra gente, sino que asumen que tratan con sysadmin no con end users y por eso, te dan un trato algo especial.
A que viene esto?, bueno, en lo que voy usando CentOS y SL, he reportado 4 bug, 2 de ellos no lo eran y otros 2 estan en espera de una respuesta, que son bug estupidos a nivel servidor (drivers libres de AMD que causan un crash pero no un panic y un estado especifico de netfilter que bien puede ser un fallo de netfilter y no de su kernel RHEL).
Lo que me lleva a escribir este post, es el hecho de que usando una distro por la cual no pago NADA, como ser CentOS, tengo un "soporte" profesional y con un tiempo de respuesta de 24hs maximo, increible.
Yo no suelo reportar algo a menos que haya estado 3 dias investigando sobre el tema, si ya no veo caso lo reporto como posible bug.
Este fue el caso de un tema que me toco con PAM y cosas que no vienen al caso, de algo MUY rebuscado, que incluso muchos RHEL boys no supieron responder via mail list (gente del ambito).
Asi que me decidí a reportar el problema como bug con lujo de detalles y todo bien especificado, aclarando que era CentOS 6.4, no RHEL.
En 24hs no solo me dieron una respuesta (WONTFIX), o sea, no se puede fixear porque no es un bug sino una limitacion de PAM (ya ahora le doy la razon a patrick de Slackware, PAM esta pesimamente programado), y no solo eso... sino que el que cerró el bug, me dejo una extensa explicacion de porque sucede "eso" y como podría yo solventarlo y que alternativas tenia... o sea, ese servicio se cobra, se llama soporte, y esta dentro del paquete que se paga a red hat anualmente.
No se si será porque llevo reportados muchos bug en Fedora, algunos en seguridad y me tomaron aprecio en bugzilla o es asi siempre, si alguno tiene testimonio que me lo comente aquí, pero me dejo perplejo.
Quizá fue por malas experiencias anteriores (Ubuntu, mas de 1 semana sin respuesta, ArchLinux, cerraban los bug o decian que era error mio sin dar explicacion, Debian habia que esperar a veces 30 dias si no era algo critico y de seguridad que pusiera en riesgo la distro), pero la realidad es que me sorprendio gratamente esta actitud.
Es obvio que cuando la limosna es grande.... y me refiero a que ellos tambien se benefician de los miles de frikis que no pagan una licencia, usan CentOS porque son frikis e investigan, cosa que no hacen las empresas, y gracias estos frikis, como yo, ellos encuentran bugs o mejoran su sistema, pero digo... esta bien, yo disfruto frikeando con Linux, es un hobbie, no un problema, y cuando no hay bug, los busco!, a ver donde encuentro algo para pulir e investigar. Es que esto de usar clones de RHEL, como decia Miguel Dark de putodeb.com, es aburrido, es cierto, nunca pasa nada, nada se jode cuelga o rompe... entonces uno tiene que inventarse algo, y como en mi caso personal ya me conozco los errores de Debian, Ubuntu... ni me molesto en usarlos.
Bueno, asi que, para los que usen CentOS, digo esto porque note que cuando mi reporte fue diciendo "CentOS 6.4", en comparacion al otro que dije "Scientific Linux 6.3", fue tomado como mas en serio, basicamente porque la gente de red hat es MUY estricta con todo, y como algunos .spec de SL son modificados, ellos no pueden tomar como valido el error ni reproducirlo a veces (ese es otro motivo por el cual me pase a CentOS), entonces al ser 100% compatible, es mas facil recibir un buen feedback.
Asi que nada... que mas decir, gratamente sorprendido y recuerdo nada mas... las palabras de un ex jefe mio, allá como hace 10 atrás, que me dijo "dale, unite a la comunidad Debian, dejá las demás distro, Debian es la mas grande" y yo... dudé, como lo hago con todo... veo que no me equivoqué.
Me animo a decir que incluso, mejor soporte que en Fedora y creo que, por algunas cosas obvias.
1.- Si algo parece ser un bug, lo analizan con MUCHO detalle en RHEL, y en caso de no serlo, su conclusión se vuelca en la respuesta del developer
2.- Existen MUCHOS mas bug por cerrar de Fedora que de RHEL, lo que hace que la gente de RHEL este menos atareada
3.- Es gente un poco... mas seria, no es que sea otra gente, sino que asumen que tratan con sysadmin no con end users y por eso, te dan un trato algo especial.
A que viene esto?, bueno, en lo que voy usando CentOS y SL, he reportado 4 bug, 2 de ellos no lo eran y otros 2 estan en espera de una respuesta, que son bug estupidos a nivel servidor (drivers libres de AMD que causan un crash pero no un panic y un estado especifico de netfilter que bien puede ser un fallo de netfilter y no de su kernel RHEL).
Lo que me lleva a escribir este post, es el hecho de que usando una distro por la cual no pago NADA, como ser CentOS, tengo un "soporte" profesional y con un tiempo de respuesta de 24hs maximo, increible.
Yo no suelo reportar algo a menos que haya estado 3 dias investigando sobre el tema, si ya no veo caso lo reporto como posible bug.
Este fue el caso de un tema que me toco con PAM y cosas que no vienen al caso, de algo MUY rebuscado, que incluso muchos RHEL boys no supieron responder via mail list (gente del ambito).
Asi que me decidí a reportar el problema como bug con lujo de detalles y todo bien especificado, aclarando que era CentOS 6.4, no RHEL.
En 24hs no solo me dieron una respuesta (WONTFIX), o sea, no se puede fixear porque no es un bug sino una limitacion de PAM (ya ahora le doy la razon a patrick de Slackware, PAM esta pesimamente programado), y no solo eso... sino que el que cerró el bug, me dejo una extensa explicacion de porque sucede "eso" y como podría yo solventarlo y que alternativas tenia... o sea, ese servicio se cobra, se llama soporte, y esta dentro del paquete que se paga a red hat anualmente.
No se si será porque llevo reportados muchos bug en Fedora, algunos en seguridad y me tomaron aprecio en bugzilla o es asi siempre, si alguno tiene testimonio que me lo comente aquí, pero me dejo perplejo.
Quizá fue por malas experiencias anteriores (Ubuntu, mas de 1 semana sin respuesta, ArchLinux, cerraban los bug o decian que era error mio sin dar explicacion, Debian habia que esperar a veces 30 dias si no era algo critico y de seguridad que pusiera en riesgo la distro), pero la realidad es que me sorprendio gratamente esta actitud.
Es obvio que cuando la limosna es grande.... y me refiero a que ellos tambien se benefician de los miles de frikis que no pagan una licencia, usan CentOS porque son frikis e investigan, cosa que no hacen las empresas, y gracias estos frikis, como yo, ellos encuentran bugs o mejoran su sistema, pero digo... esta bien, yo disfruto frikeando con Linux, es un hobbie, no un problema, y cuando no hay bug, los busco!, a ver donde encuentro algo para pulir e investigar. Es que esto de usar clones de RHEL, como decia Miguel Dark de putodeb.com, es aburrido, es cierto, nunca pasa nada, nada se jode cuelga o rompe... entonces uno tiene que inventarse algo, y como en mi caso personal ya me conozco los errores de Debian, Ubuntu... ni me molesto en usarlos.
Bueno, asi que, para los que usen CentOS, digo esto porque note que cuando mi reporte fue diciendo "CentOS 6.4", en comparacion al otro que dije "Scientific Linux 6.3", fue tomado como mas en serio, basicamente porque la gente de red hat es MUY estricta con todo, y como algunos .spec de SL son modificados, ellos no pueden tomar como valido el error ni reproducirlo a veces (ese es otro motivo por el cual me pase a CentOS), entonces al ser 100% compatible, es mas facil recibir un buen feedback.
Asi que nada... que mas decir, gratamente sorprendido y recuerdo nada mas... las palabras de un ex jefe mio, allá como hace 10 atrás, que me dijo "dale, unite a la comunidad Debian, dejá las demás distro, Debian es la mas grande" y yo... dudé, como lo hago con todo... veo que no me equivoqué.
12 comentarios:
Si la verdad es que funciona muy bien (que aburrimiento) a no ser alguna tontería que me sale con la mariquita (notificaciones ABRT) que creo que la quitare del inicio del sistema y también que se me colo algún paquete de rpmfusion que después de arreglarlo lo elimine del sistema, cambiándolo por atprms.
El resto funciona como un reloj
Aparte de la estabilidad, tal vez el mejor punto de CentOS sea que es un clon de RHEL, por lo tanto hay una empresa profesional detrás que tiene que corregir los errores no por gusto (como en Debian, lo que puede hacer que se retrase) sino porque para eso le pagan.
Ahora bien, también hay que darle su punto a Debian por esto: justamente ellos lo hacen gratis y tienen muchos más bugs porque ofrecen muchos más paquetes en su repositorio oficial. Si me preguntaran mi opinión, Debian gana en programas ofrecidos (y tiene que darle las gracias a Ubuntu, aunque a alguien le pese) y CentOS en estabilidad.
PD: ¿Qué ha pasado con putodeb.com?
Está claro que practicamente en linux sólo hay dos madres que son las que hacen casi todo el trabajo, redhat y debian. Y mal que nos pese el control de calidad y desarrollo que se puede hacer en una empresa con intereses económicos, y por tanto con profesionales trabajando en ella, tiene un plus a la hora de conseguir un sistema operativo fiable. Paradojicamente personas como tu, que teneis los conocimientos suficientes para aportar mejorías en proyectos comunitarios donde más se necesitan (como en debian o archlinux) se ven mejor recibidos en redhat donde no van a rechazar ninguna aportación que ayude a mejorar aunque simplemente sea reportar bugs. Un profesional de verdad sólo quiere realizar su trabajo lo mejor posible (su futuro depende de ello), en proyectos comunitarios algunas veces el ego y la soberbia están por encima del afan de perfeccionamiento. En descargo habría que decir que mientras redhat principalmente trata con sysadmins, debían y el resto muchas veces tienen que verselas con gente con escasos conocimientos.
Aprovecho para preguntarte si sabes si en el futuro redhat va a implementar también systemd. De ser así debían sería casi la única de las grandes (slackware también pero a esta la veo como reliquia)que tendría el script de inicio clásico compatible con unix.
Tenés toda la razón, no por nada, Allan McRae de ArchLinux me cerraba el bugreport de un fallo en GCC diciendo que NO era un bug, mientras en una charla que sostuvo con Dan, que la tengo en favoritos y salio en una lista de mail, le decia que tenia ese problema con GCC y no sabia que era... o sea, aceptaba el error con Dan, otro del team, pero a mi me decia de pesimas maneras que no era un bug... algo increible. Lo mas triste, como bien decís, es que mi idea era aportar (he llegado a instalar 4 VM's al dia por Arch y reinstalar 3 veces en un dia) para mejorar la distro, porque pensaba que su arquitectura, su armado, eran impecables en concepto, asi como pacman, pero no me fue posible lidiar con esa gente, dado su ego, mismo un developer de Arch que habla español, me dijo "Desde que Allan se convirtio en developer y se ocupa de GCC ya no es el mismo", y bueno... ese no era mi problema... para eso estan los psicoanalistas.
Tengo entendido, que en RHEL7, que estará basado en Fedora 18, se incluira systemd como reemplazo de upstart+sysvinit, el desktop por defecto aun esta en debate si será gnome 3, xfce o cinnamon, pero muchos apuestan a xfce, asi que eso no sabria decirte.
En lo que a mi respecta, systemd no me gusta NADA, y te digo que a muchos sysadmin, tampoco, sin embargo, fuentes confiables, admin importantes que trabajan en Red Hat, me han comentado que en realidad systemd tiene muchas ventajas frente a sysvinit y upstart, pero.... que las versiones que vemos en Fedora, no son justamente las mas pulidas ni la que llevará RHEL7, o sea que, piensan tomar lo mejor de todas las versiones de cada Fedora que usó systemd, pulir el paquete y meterlo, de todos modos, será compatible con scripts tipo sysvinit, eso si me lo han confirmado.
Asi que habrá que ver, que limitaciones o beneficios trae systemd en RHEL7 y evaluar que conviene hacer. Claro está, que prefiero el script de inicio estilo Slackware... pero eso es otro tema personal.
Debian migró actualmente a upstart de Ubuntu, lo podés notar en Debian 6 y en testing 7, Slackware aun conserva el viejo sysvinit clasico y lo seguira usando por siempre.
Dudo, que Red Hat meta la pata con RHEL7 y systemd, porque sino, perderia un enorme mercado y reputacion, asi que habrá que ver COMO lo implementan. Aclaro, la idea de systemd no es mala, pero, no me gusta que TODO dependa de un demonio, que claro esta puede tener fallas, a menos que Lennart programe con 0 bug y 100% eficiente, y tampoco me agrada que se haya reemplazado el rsyslog de siempre, y hasta el momento, el syslog de systemd no tiene la opcion de loguear en un servidor remoto como lo hace rsyslog, hasta el momento, por eso digo... hay que ver COMO lo implementan.
Mis "no" contra migrar en un posible futuro gris a Slackware, es el tema de que me parece de lo peor no tener un package manager, por mas que muchos digan que existen pro y no contra, en entornos de produccion, es una contra enorme. Lo mismo con el kernel, el no soportar fallos de seguridad de kernel, Slackware hasta la 9.1 sacaba una update por cada CVE de seguridad, hoy en dia no, y lo pueden confirmar con AlienBOB en freenode.
Migrar a Debian... lo unico que no me cierra es el tema de apt y .deb, es decir, tiende mas a fallos que rpm + yum (futuro DNF y actual en Fedora 18), basicamente porque he visto errores y si bien son reparables, el tiempo es mayor, en rpm cuando se rompe la DB, se repara en segundos, no llega al minuto y nunca me ha dado problemas. Ademas de que ODIO que Debian cambie las cosas a su gusto, como hace con HTTP, cuando todos usan /etc/httpd/conf/... etc, ellos lo llaman apache2 e incluyen un monton de .conf para """"facilitar""" las cosas... cuando en realidad la complican, y eso en RHEL o Slack, no pasa. Sacando de lado el tema de apt, .deb y eso, Debian me parece buena opcion, ah, y deberian mejorar la velocidad de su kernel-libre... porque es mas lento que el vanilla o el de RHEL.
Si, ABRT lo he sacado, y los errores son por SELinux no configurado, pero eso se arregla... desactivando SELinux y el demonio de ABRT. RPMFUSION para RHEL... tiene poco y nada de paquetes, por no decir que si tengo 3 instalados es mucho, la verdad es que atrpms, rpmforge, epel son los mas usados.
Eso es cierto, lo se, Debian comparado a RHEL, le patea el culo en paqueteria, y si, lo hacen por gusto no por dinero, pero.... no se si en RHEL no es un poco y un poco, porque.. que necesidad tenia el tipo que me cerro el bug en responderme y darme las explicaciones del caso si yo no soy un cliente?. Ojo, Debian tenia tantos paquetes antes de Ubuntu, ahora sumo algunos mas, pero ya los tenia, siempre fue la distro con mas paquetes soportados oficialmente, y por eso algunos admin la eligen. Segun Red Hat, el tema de los paquetes se debe a que, textualmente me lo han explicado desde alli: "Soportamos un numero preciso y minimo de paquetes, porque con los soportados es posible hacer todo, si eres ingeniero red hat y sabes como hacer las cosas, y es mejor soportar poco con maximo control y calidad que mucho a medias"
PD: No se, acabo de darme cuenta de que existe el dominio, pero carga nada, en blanco.
Una pena lo de Arch. He seguido lo que te pasó en su momento y es lamentable por lo que muchos pensamos que Arch podría ser la distro ideal y no lo es por culpa de ellos mismos. Ahora parece que Allan trata de fastidiar a Manjaro con pequeñas zancadillas... patético. He dejado de usar Arch precisamente por el cambio a systemd unido a que ahora me apetece más disfrutar de lo estable bien hecho en debian y SL (para ser justos he usado arch 2 años con cambios importantes sin ningun problema digno de mención hasta que llegó Systemd).Systemd tiene muchas ventajas pero ahora mismo está en pañales. Parece que si todo sale bien va a ser un paso evolutivo en linux. Pero no creo que esté maduro para el próximo Redhat que puede salir antes de acabar el año. Lo que me hace dudar tras leer tu articulo es el cambio usr/move o sea el cambio de jerarquia de archivos unix. Según tu explicas (por lo menos a mi me parece convincente lo que dices) este cambio es debido a un fallo de diseño de systemd. De ser así es como un poco chapuzero. Y aunque no es justo también me hace desconfiar que el creador de systemd es el creador de Pulseaudio, proyecto con muy buenas intenciones pero es lo primero que desinstalo cuando alguna distribución lo trae por defecto porque siempre me falla.
En lo del kernel de debian es verdad que es lento. Estoy probando el kernel liquorix y nunca había notado tanta diferencia entre el kernel oficial y uno modificado. En Arch lo había probado y la diferencia era imperceptible.
Slackware lo veo como una reliquia del pasado con su toque masoquista porque hasta el instalador de gentoo resuelve depedencias.
Estoy esperando que el encargado de mantener putodeb me mande algún correo al respecto, cuando se nos quedo en blanco la web el amigo Milord estuvo revisándola y no encontró ningún fallo, debemos suponer que el problema es del servidor ¿?
Pues eso que espero a que Milord me cuente algo pues él es el experto.
Puede ser un error de la plantilla CSS, php si no hubo cambios no creo, y mysql deberia dar error de connect database. Yo miraria los log de apache error_log, messages de kernel, mysql.
Yo creía que la página había desaparecido, es que lleva como un mes así...
Si te gusta reportar bugs, porque no lo haces con el kernel en Fedora, en las ultimas semanas ha causado varios kernels panics a varios usuarios aunque no tengan instalados controladores propietarios... llegando al extremo de excluir de las actualizaciones al kernel :|
Reporto a fedora, rhel y kernel.org. Habria que ver que condiciones causaron panic, yo tengo F18 y 17 en dos PC, la F17 tiene driver nvidia desde rpmfusion, no tuve un solo problema en esta semana.
Publicar un comentario