Solución 1:
Compartiré mis experiencias trabajando como tecnólogo en algunos campos diferentes...
(Precaución:esta es una historia sobre Red Hat y cómo crecí profesionalmente con él)
Empecé a trabajar con Linux profesionalmente en 2000-2002. Esto fue durante la amplia adopción de Red Hat y Red Hat Professional Editions (6.x, 7.x, 8.0). Estos estaban disponibles para su descarga gratuita, así como conjuntos empaquetados en caja. Se pueden encontrar fácilmente en las tiendas minoristas de computadoras.
Para mí, esto tuvo la ventaja de involucrar a aficionados y usuarios domésticos con el mismo producto que comenzaba a surgir en la empresa. Mi trabajo en ese momento era trasladar los sistemas de servidores de clientes de Unices comerciales (HP-UX, AIX y SCO) a la plataforma Red Hat.
¡El ahorro de costos fue sustancial! Reemplazar los servidores HP9000 PA-RISC de $100k+ por servidores Compaq ProLiant Intel de $40k fue una ganancia absoluta en costo y rendimiento.
Entonces, ¿por qué Red Hat?
Red Hat fue el primero en llegar a este mercado y obtuvo soporte crítico para el negocio, el proveedor y el hardware. Ver a los grandes proveedores de aplicaciones usar Red Hat como plataforma de destino selló el trato. Los usuarios aficionados como yo pudimos transferir las habilidades perfeccionadas en casa a nuestros entornos de trabajo con facilidad. La comunidad estaba creciendo. ¡Dominaron las pilas de Slashdot, Freshmeat y LAMP! Fue un buen momento para Linux.
En este punto, era responsable del desarrollo y la evaluación de las distribuciones de Linux como plataforma para una solución de software ERP patentada. Me quedé con Red Hat. De vez en cuando, probaba con otra distribución (Mandrake, SuSE, Debian, Gentoo), pero encontraba problemas con el empaquetado, el soporte de hardware (servidores o periféricos), el (tamaño del) comunidad o algún otro factor decisivo.
Un ejemplo:estaba usando hardware Compaq/HP ProLiant equipado con tarjetas PCI-X de expansión Digi Serial y software de fax de producción Esker VSIfax. Los dos últimos solo tenían soporte de controlador para los sistemas operativos Red Hat. En algunos casos, el software solo se entregaba en forma binaria o RPM, lo que impedía un uso sencillo en otras variantes de Linux.
El impulso es importante en el mundo de la tecnología de la información
Nadie quiere ser de los que recomiendan perder solución o proyecto que finalmente queda huérfano, por lo que se queda con opciones seguras. Estaba administrando una pila de tecnología que necesitaba funcionar de manera confiable y tener varias capas de soporte. La elección de una distribución diferente en ese punto tendría justo. estado. irresponsable.
La luna de miel de Red Hat terminó para mí en 2003 con la descontinuación de las ediciones profesionales del software. Red Hat Enterprise Linux fue el reemplazo y vino con bastante bagaje... Costo (modelo caro basado en suscripción), accesibilidad (reducción de la base de usuarios y la comunidad) y confusión general sobre el futuro...
Empecé a buscar alternativas, reevaluando Gentoo, Debian y SuSE. No pude obtener el soporte adecuado en todos los componentes de nuestra pila de tecnología. Me vi obligado a seguir con el ecosistema de Red Hat... Debido al enorme cambio de costos asociado con Red Hat Enterprise Linux, terminé ejecutando un Red Hat 8.0 altamente modificado durante años más allá de su final de vida. No fue hasta que maduraron los clones de RHEL (Whitebox Linux y, más tarde, CentOS) que preparé un cambio real para alejarme de mi estándar.
La principal ventaja de los derivados de Red Hat era y es Compatibilidad binaria con las versiones pagas de RHEL. Incluso es posible realizar conversiones in situ entre RHEL y CentOS, y viceversa. Continué trabajando con sistemas similares a RHEL hasta que di el siguiente paso en mi carrera...
Más tarde me encontré en la industria del comercio financiero de alta frecuencia, donde era responsable de I+D e ingeniería de Linux para sistemas críticos de comercio automatizado. El énfasis en este mundo era la velocidad , mediante cuidadosas pruebas y ajustes. Nuevamente, el soporte de hardware fue clave. Tendría tarjetas de red específicas, hardware especializado, hardware de servidor o bibliotecas de aplicaciones que solo estaban certificadas para RHEL o sistemas similares a RHEL. Incluso en los casos en que las cosas se podían compilar para otras variantes de Linux, surgió el factor comunitario. Cuando estaba en el punto en el que necesitaba investigar un problema, a menudo se trataba de un problema que podía rastrearse hasta notas o comentarios en los informes de Red Hat Bugzilla o, a veces, simplemente enviaba un parche o solicitaba la próxima versión. .
Cuando comencé a profundizar en las redes de baja latencia y el ajuste del kernel, comencé a diseccionar los kernels RHEL estándar y los kernels RHEL MRG Realtime. Noté cuánto trabajo cuando estaba en los lanzamientos... Más de 200 parches para un kernel kernel.org vainilla. Lea los comentarios y las notas de confirmación. Puede tener cosas pequeñas como sysctl parámetros expuestos o valores predeterminados más sensatos aplicados. Red Hat paga a las personas para parchear, probar y solucionar estos problemas. No vi el mismo compromiso de otras distribuciones de Linux... Agregue el hecho de que la plataforma empresarial está garantizada para tener seguridad real, corrección de errores y compatibilidad con backport durante años .
Así que eventualmente me mudé a otra firma financiera que era casi todo Gentoo en el servidor y escritorio... Fue un desastre para mí. Viniendo del mundo de Red Hat y CentOS, encontré numerosos problemas de estabilidad y administración con la configuración de Gentoo. El control de versiones fue el mayor problema, pero la disminución del apoyo de la comunidad y la falta de pruebas reales también fueron preocupaciones. Empecé a introducir RHEL en el entorno porque algunos de nuestros software de terceros lo requerían...
Pero había un problema... Mis desarrolladores estaban acostumbrados a Gentoo y tenían rutas de actualización relativamente fáciles para las bibliotecas principales y las versiones de la aplicación. No pudieron adaptarse a tener las versiones principales fijas en las que se estandariza Red Hat Enterprise Linux. El proceso de desarrollo y lanzamiento estuvo plagado de preguntas sobre por qué GLIBC 2.7 no se podía injertar en RHEL 5.x o por qué una determinada versión de compilador o biblioteca no estaba disponible. Cuando se les dijo que las actualizaciones entre versiones principales de RHEL/CentOS esencialmente requerían reconstrucciones completas, perdieron mucha confianza en la solución.
En este punto, me di cuenta de que Red Hat se estaba moviendo demasiado lento para los desarrolladores que querían estar a la vanguardia. RHEL 6.x fue una actualización muy necesaria y bienvenida, pero este tema se hizo más evidente una vez que comencé a entrevistarme con nuevas empresas y empresas que se suscribieron a los principios de DevOps.
Hoy...
Un número cada vez mayor de desarrolladores y usuarios de Linux provienen de entornos Linux que no son de Red Hat, SuSE ni empresariales.
- Están usando Ubuntu o Debian...
- No tenían que lidiar con hardware de la vieja escuela ni con el soporte de grandes proveedores.
- Están escribiendo sus propias aplicaciones desde cero (autosuficientes).
- La virtualización y la computación en la nube abstraen la capa de hardware, por lo que las preocupaciones sobre controladores de controladores RAID originales, periféricos PCI-X o agentes de administración distribuidos en binario ni siquiera están en el radar.
- Estos usuarios quieren las herramientas y el espacio de usuario al que están acostumbrados.
Así que hay un conflicto... Estos usuarios no entienden por qué estarían restringidos en las versiones de la aplicación o la biblioteca. Los administradores de la vieja escuela aún se están adaptando al nuevo paradigma. Argumentos que parecen estar arraigado en la religión son realmente solo funciones de cómo las personas desarrollaron sus respectivos conjuntos de habilidades.
Vi un anuncio de trabajo hoy para un puesto de ingeniero de DevOps Linux de alto nivel que decía:
Debe ser competente a experto en distribuciones de Linux basadas en Debian (Ubuntu y sus variantes están bien. Red Hat pasable , pero no preferido)
Así que supongo que funciona en ambos sentidos... Me alejé de las oportunidades laborales porque los 800 servidores CentOS que estaría administrando estaban programados para convertirse a Ubuntu. Claro, Linux es Linux... pero no sentí que sería tan efectivo como podría ser... He tenido problemas con las instalaciones de Debian y deseaba que se estuviera usando una distribución basada en RPM. He tenido discusiones acaloradas sobre los méritos de varias plataformas (usualmente colocando a Gentoo al final de la lista).
Entonces, ¿qué es lo correcto para SU entorno? Eso depende. He estado en empresas donde los ingenieros de sistemas toman las decisiones, así como en organizaciones donde los desarrolladores son los reyes. Creo que el mejor arreglo es cuando los desarrolladores y las personas que respaldan los sistemas acuerdan la plataforma. Pero aparte de eso, piense en el soporte a largo plazo, la facilidad de uso, la comunidad y lo que se adapte a su pila de aplicaciones de la manera más adecuada.
Un desarrollador talentoso debería poder trabajar en un entorno similar a RHEL o Debian. Y bueno, las plataformas de desarrollo deben reflejar el entorno de producción. Vas desde allí...
Solución 2:
Actualmente trabajo en un entorno que ha utilizado Linux durante más de una década. Todos en la oficina usan diferentes distribuciones en sus escritorios, así como en los servidores. Como tal, las opciones de distribución tienden a girar en torno a una serie de cosas sin ningún orden en particular:
- Historia - Obviamente, sistemas como RedHat y Debian existen desde hace mucho tiempo. Como tal, el adagio "si no está roto, no lo arregles" puede usarse para estos. La actualización se vuelve más fácil si el software es compatible con una distribución.
- Familiaridad - Similar a Historia, sin embargo, todos tenemos nuestros favoritos. Me inicié en Debian y migré a Ubuntu (una decisión difícil en ese momento porque tiendo a comprometerme con una comunidad). Por el contrario, es un fastidio tener que recordar cómo hacer las cosas en una docena de distribuciones diferentes (sin mencionar las que se construyen desde cero).
- Soporte - Migré a Ubuntu principalmente porque aprecié lo que estaban haciendo en cuanto a ofrecer soporte pago. Ese fue un punto de venta si alguna vez un cliente tenía una preocupación sobre el funcionamiento de un sistema a largo plazo. Similar al enfoque de RedHat (pero el infierno de RPM estaba sucediendo en ese momento). También tenemos varios servidores RedHat por este motivo.
- Dependencias - Algunos softwares son más fáciles de usar en algunas distribuciones simplemente porque los paquetes dependientes son más fáciles de obtener o construir. Como ejemplo de esto sería oVirt en RedHat. No hay paquetes para algunos softwares en algunas distribuciones. Y podrías compilarlo, pero ¿por qué lo harías si el paquete estuviera ahí en otra distribución?
- Granularidad - Las distribuciones como Gentoo ofrecen un control más preciso sobre el control de versiones y la granularidad del cambio de software. Otras distribuciones tienen "fijación" en varias formas, pero eso aún no es tan controlable o confiable.
- Enlace - Si bien es posible compilar desde la fuente en la mayoría de las distribuciones, algunas distribuciones son mejores que otras. Esto puede tener un efecto, por ejemplo, si su proyecto parchea las bibliotecas existentes para ampliar la funcionalidad.
- Belleza - Algunas distribuciones son simplemente más atractivas. Todos los geeks saben que es solo una tontería (y probablemente podría salirse con la suya como una aplicación web en estos días), pero algunos clientes están asombrados con estas cosas, y todos lo sabemos.
- Estabilidad - Algunas distribuciones transmiten versiones "estables" de software en lugar de "pruebas", "experimentales", etc. Esto puede significar mucho si sabe que la versión en la que está construyendo eventualmente llegará a un consenso sobre la estabilidad. Puede desarrollarse en "experimental" sabiendo que para cuando termine su proyecto habrá llegado a "estable" y será bueno confiar en él.
- Administración de paquetes - Si está desarrollando algo a diario, y va a salir a miles de máquinas de un solo golpe, entonces probablemente desee algo que facilite la creación, el mantenimiento y el seguimiento de paquetes en esos sistemas.
- Coherencia - Esto es más un argumento a favor de lo lo mismo distribución Se cometen menos errores (y menos errores de seguridad) cuando las personas pueden concentrarse en una distribución en lugar de varias.
- Calendario de lanzamiento predecible - Si desea asegurarse de que su software siga siendo compatible, las actualizaciones planificadas ofrecen cierto tipo de estabilidad.
- Seguridad - Algunas distribuciones tienen equipos de seguridad activos cuyo trabajo es responder de inmediato a riesgos de seguridad genuinos en cualquier paquete aprobado.
Esas son solo algunas cosas que me vienen a la cabeza con respecto a las razones por las que se eligió cada sistema. No veo ninguna luz guía o preferencia de una distribución sobre otra en esta decisión. La diversidad y la elección pueden ser excelentes y ofrecerle algunas opciones realmente buenas para comenzar un proyecto rápidamente, pero también es la soga que puede colgarlo. Asegúrate de pensar con anticipación en lo que vas a necesitar. Planifique cuáles son las necesidades del sistema y cuándo se actualizará o retirará. No asumas que siempre serás tú quien lo mantenga.