Me voy de Red Hat (Enterprise Linux)
(jeffgeerling.com)- Jeff Geerling, que siguió dentro del ecosistema de Red Hat incluso después del fin de CentOS, decidió dejar de dar soporte oficial a Enterprise Linux a raíz del cambio en el acceso al código fuente de RHEL
- La nueva política cambia el flujo de código fuente necesario para reconstruir RHEL, lo que sacude la base de distribuciones derivadas como Rocky Linux y AlmaLinux
- Aunque bajo la GPL se puede poner el código fuente detrás de una suscripción paga, los términos que permiten cancelar la suscripción si se redistribuye podrían derivar en problemas de confianza legal y comunitaria
- Desarrolladores y mantenedores de EPEL/Fedora ahora cargan con la obligación de rediseñar su infraestructura de pruebas para ajustarla a la Red Hat Developer Account y a 16 licencias de RHEL
- Geerling considera que Red Hat está perdiendo por ganancias la confianza que construyó en la comunidad de código abierto, y Rocky Linux y AlmaLinux dicen que buscarán cada uno su propio camino para sobrevivir
El problema del acceso al código fuente de RHEL vuelve a estallar tras el fin de CentOS
- Hace 2 años, Red Hat puso fin a CentOS, una distribución gratuita de Enterprise Linux ampliamente usada
- A la comunidad de usuarios de CentOS la llamaron “freeloaders”, por aprovechar el trabajo de Red Hat sin pagar, y Geerling dice que él mismo se veía como parte de esa comunidad
- CentOS servía como base para que desarrolladores de código abierto, contribuidores del kernel de Linux y desarrolladores de software hicieran pruebas y compilaciones
- Geerling subraya que Red Hat también construye sus productos sobre Linux, que no creó ni posee
La promesa de 2020 y el daño a las distribuciones derivadas
- Se menciona que Red Hat prometió en 2020, después de los cambios en CentOS, que seguiría publicando el código fuente en git
- Este cambio también está causando grandes dificultades a proyectos derivados de RHEL de larga trayectoria, como SDL/PUIAS, que se mantuvieron incluso más tiempo que CentOS
- Geerling cree que estas distribuciones están sufriendo daños colaterales en la situación actual
Rocky Linux y AlmaLinux evitaron una salida masiva
- Geerling siguió dentro del ecosistema de Red Hat incluso después del fin de CentOS por dos razones
- Algunos empleados de Red Hat intentaron dialogar preguntando “cómo podemos hacerlo mejor” en vez de atacar a la comunidad usuaria del código abierto
- Rocky Linux y AlmaLinux aparecieron y se convirtieron en objetivos estables de trabajo de código abierto para los desarrolladores
- Sin embargo, ambas distribuciones dependían de la estructura en la que Red Hat compartía el código fuente
El flujo tradicional de publicación del código fuente de RHEL
- El método anterior podía entenderse en este orden
- Red Hat toma una copia de Linux
- Le agrega sus propios cambios para convertirla en Red Hat Enterprise Linux
- Publica una nueva versión
- Actualiza el repositorio del código fuente con los datos necesarios para compilarla desde cero
- Desde esta postura, en el código abierto lo esencial es que el código fuente esté abierto y que todos compartan su trabajo para beneficio mutuo
- La licencia GPL que usa Linux exige legalmente compartir el código fuente
- Considera que, sin ese intercambio, habría sido difícil que existieran tantas distribuciones Linux como Debian, Arch, Mint, Ubuntu, PopOS y Fedora
Código fuente detrás de un muro de pago y polémica por los términos
- Red Hat decidió poner el código fuente detrás de un paywall
- Geerling reconoce que, técnicamente, este método puede ser posible bajo la GPL
- Pero critica que sea una forma grosera y molesta, dado que buena parte del código que se bloquea se basa en código abierto creado por otros
- El punto más delicado son los términos de suscripción actuales de Red Hat
- Red Hat dice que puede cancelar la cuenta si un usuario descarga y redistribuye el código fuente
- Si alguien descargara el código con una suscripción de Red Hat, compilara una nueva versión de Rocky Linux y luego Red Hat cancelara esa suscripción, Geerling cree que sería un caso digno de verse en tribunales
- No está claro si la comunidad podría reunir el dinero para enfrentar a los poderosos abogados de IBM, aunque menciona a Oracle como un actor que sí podría hacerlo
- Sostiene que la medida de Red Hat se pega al límite de la legalidad de las condiciones GPL de Linux, y como análisis relacionado cita un texto de Software Freedom Conservancy
La idea de que se está presionando a las distribuciones derivadas
- Por lo que observa Geerling, todo apunta a que Red Hat intenta presionar a distribuciones derivadas como Rocky, Alma y Oracle Linux
- Cree que Red Hat busca inquietar a los usuarios de esas distribuciones para empujarlos hacia sus suscripciones
- También añade una interpretación cínica: que esta medida sería necesaria para asegurar ganancias de corto plazo y satisfacer a IBM
La imagen histórica de una empresa de código abierto frente al contraste actual
- En el pasado, Red Hat era una empresa rebelde y se posicionaba como el actor pequeño que sacudía a las compañías tradicionales de software privativo usando anuncios con citas de Gandhi y la bandera del código abierto
- Hoy, Red Hat ocupa una posición casi predeterminada cuando se trata de ejecutar Linux en grandes empresas
- Geerling cree que la descripción de Cory Doctorow sobre la degradación de plataformas también encaja con Red Hat
- La idea es que una plataforma primero trata bien a sus usuarios, luego los explota en favor de sus clientes empresariales y, al final, explota también a esos clientes para extraer valor para sí misma antes de morir
- Para él, Red Hat está tirando por ganancias la buena voluntad que acumuló en la comunidad de código abierto, al menos en lo relacionado con Linux
La carga operativa que ahora enfrentan desarrolladores y mantenedores
- Desarrolladores como Geerling, mantenedores del repositorio EPEL y mantenedores de Fedora están preocupados por el impacto de largo plazo
- A estas personas se les indica que se registren en una Red Hat Developer Account para recibir 16 licencias de RHEL para pruebas
- Geerling considera que esto lo obliga a rehacer su infraestructura de pruebas y automatización para ajustarla a las licencias de Red Hat
- Debian, Ubuntu, FreeBSD y Rocky Linux no exigen este tipo de proceso
- También rechaza que empleados de Red Hat digan que se use CentOS Stream
- Hay una razón por la que Rocky y Alma Linux se descargaron millones de veces
- Considera que CentOS Stream no es un sustituto de CentOS
Fin del soporte a Enterprise Linux y preocupación por Ansible
- Geerling eliminó desde el viernes pasado el soporte oficial a Enterprise Linux de todo su trabajo
- También está recibiendo preguntas sobre Ansible
- Describe a Ansible como Red Hat Ansible Automation Platform, es decir, un producto de IBM
- Dice que no cree que Ansible vaya a intentar cerrar el acceso, pero considera anormal que siquiera haya que contemplar esa posibilidad por un momento
- Su postura es que no quiere construir nada sobre un ecosistema donde a los usuarios del código abierto se les llama freeloaders y donde ocurren dos grandes sacudidas consecutivas, sin aviso, en medio del ciclo de lanzamientos
Rocky y Alma anuncian que encontrarán una salida
- Geerling no cree que esto vaya a beneficiar a Red Hat en el largo plazo
- Resume la situación como algo triste para tres grupos
- Los usuarios que usaban CentOS y desarrollaban herramientas para atraer gente al ecosistema de Red Hat
- Red Hat, que antes era una empresa que luchaba por el código abierto y ahora levanta barreras alrededor de su propio código fuente
- Las personas que siguen dentro del ecosistema de Red Hat y ahora tienen que cargar con los problemas de licencias y la fuga de la comunidad de código abierto
- Rocky Linux y AlmaLinux anunciaron por separado que encontrarán la forma de seguir adelante
- Geerling dice que seguirá apoyando a Rocky Linux y AlmaLinux en la medida de lo posible, pero que ya no puede asegurar que en el futuro vaya a poder dar soporte a Enterprise Linux
1 comentarios
Comentarios en Hacker News
Me parece que este tipo de comentario improvisado, tan emocional y con una relación laxa con los hechos, no es muy constructivo
No me gusta esta decisión de Red Hat y me preocupa mucho la dirección que está tomando Red Hat. Por primera vez en más de 10 años, estoy reconsiderando el ecosistema en el que se basan mi trabajo y las empresas donde tomo decisiones
Cuesta creer que el liderazgo de Red Hat siga preocupándose mucho por el open source y, aunque sí le importe, creo que ha demostrado que puede perjudicar al open source para aumentar ingresos a corto plazo
Dicho eso, hasta donde sé la expresión freeloaders la usó una sola persona, no está claro a quién se refería en ese contexto, y tampoco es seguro si era una opinión personal o la postura de la empresa. Tampoco parece que se refiriera a quienes usaban CentOS y de verdad contribuían a la comunidad
En una organización grande siempre habrá personas con opiniones que no representan a toda la empresa, y pintar a toda la organización por la forma de expresarse de una sola persona es injusto e improductivo
No entiendo cuál es el objetivo aquí. ¿Polarizar todo en términos de buenos y malos, para que todos terminen defendiendo solo a su propio bando por miedo a que “el otro lado” use sus palabras y decisiones para atacarlos?
Me gusta mucho el contenido de OP, pero me preocupa un poco que se haya metido demasiado en la fórmula del éxito en YouTube de apelar a las emociones, especialmente a la ira y al enojo, y que por eso esté tratando este tema de forma demasiado emocional
No todos los usuarios de CentOS eran parásitos, y lo mismo aplica a los usuarios de sus sucesores espirituales. Pero la mayoría de los usuarios de CentOS no devolvía nada ni a CentOS ni a la comunidad más amplia de software libre/open source
Además, una parte considerable usaba CentOS porque quería todos los beneficios de Red Hat EL sin querer pagar el costo
Eso suena bastante a parasitismo. Las licencias open source copyleft permiten el parasitismo [1], y también permiten que Red Hat restrinja el acceso al código fuente. Mientras cumpla sus obligaciones de licencia con sus clientes, no hay problema
Red Hat invierte una enorme cantidad de dinero en el ecosistema de software libre/open source, y me parece totalmente justo empujar a los clientes que claramente pueden pagar a que paguen la suscripción. Los demás usuarios tienen muchas alternativas
[1] Si fuera una licencia no copyleft, por supuesto Red Hat no tendría obligación de proporcionar el código fuente
“Después de que pasó el tiempo para eliminar la mayoría de los clones, Red Hat también eliminó la versión oficial gratuita de su producto principal de pago. En su lugar, pasó a ofrecer una versión gratuita de prueba y lo anunció con palabras de buena imagen, como participación de la comunidad. En la práctica, desde el punto de vista de Red Hat, recortó a quienes podrían verse como una masa de parásitos. Esta medida también incluyó el despliegue gratuito en producción de RHEL para desarrolladores, pero solo se permitía hasta 16 máquinas”
https://www.theregister.com/2023/06/23/red_hat_centos_move/
Con el segundo post sobre Red Hat sentí algo parecido. A veces publica cosas interesantes, pero en la mayoría de los casos el marketing estilo YouTube es demasiado exagerado
Sé que lo hace a propósito para conseguir métricas, y espero que ese enfoque le funcione y le atraiga al público que quiere. Viendo que no lo cambia, seguramente así es
Recuerdo cuando salió el anuncio original de que eliminarían CentOS y lo reemplazarían por CentOS Stream. Muchos empleados de IBM, es decir, de Red Hat, defendían el cambio describiendo a los usuarios de CentOS como gente que usaba gratis un producto de pago
También hubo mucha gente en Hacker News, Reddit y otros lugares que lo defendía así. Ojalá no intentáramos reescribir la historia
Deberían temer la reacción negativa cada vez
La gente de verdad tiene que estar lista para irse. Si no, termina pasando lo mismo que en Reddit, donde al final todo vuelve a quedar como antes
Entiendo la postura de Jeff, pero creo que esta ya es como la tercera vez en una semana que llega a la portada de HN con algo sobre este tema
Siento que a esta piedra ya no se le puede sacar más sangre. Jeff es libre de agarrar su pelota e irse a casa, y la verdad Red Hat también
Pero esto ya me parece que pasó la etapa de “noticia destacable”, y no creo que la conversación avance más porque Jeff publique otro post expresando su frustración
No sé si hacían falta tres posts, ni si todos tenían que llegar a la portada de HN, pero en general tampoco me parece tan grave. Al final, así votó la gente
Es broma, pero hace unos días yo también tuve que googlearlo. Últimamente no sigo muchos canales de YouTubers de tecnología
Citando la expresión de Jeff, la forma anterior era que Red Hat tomaba una copia de Linux, le añadía la “salsa secreta” que hacía que se convirtiera en Red Hat Enterprise Linux, publicaba una nueva versión y actualizaba en el repositorio de código fuente todos los datos necesarios para reconstruirla desde cero
Para agregar algunos matices, ahora esa parte de la salsa secreta ya no existe. Todo el código secreto o las cajas negras están expuestos públicamente en CentOS Stream
Red Hat ya no desarrolla RHEL detrás del firewall corporativo; hace todo el trabajo públicamente en CentOS Stream. Hay una excepción con los CVE de seguridad, pero en la práctica entran a CentOS Stream y a RHEL al mismo tiempo cuando se levanta el embargo
Al final, este punto surge de ignorar deliberadamente a CentOS Stream. Los clones de RHEL solo tienen que seguir CentOS Stream, y también pueden replicar esa “salsa secreta” del flujo de CI/CD de CentOS Stream
Hoy en día, clonar RHEL es mucho más fácil que en cualquier otro momento del pasado
Hace falta más esfuerzo que hace unas semanas para replicarlo haciendo coincidir incluso los bugs. Y además eso implica hacer ese trabajo en paralelo con el propio Red Hat, así que hay duplicación de esfuerzos
Además, viendo que forzaron a Rocky y AlmaLinux a cambiar esto a mitad del ciclo de lanzamientos de 9.x, y que antes también terminaron CentOS en medio del ciclo de lanzamientos de 8.x con menos de 24 horas de aviso, cuesta sentir que este cambio se hizo “solo para mejorar el desarrollo de CentOS y RHEL”
Si de verdad ese hubiera sido el objetivo, tendrían que haberlo anunciado con al menos unas semanas de anticipación, idealmente unos meses, para que la comunidad pudiera planificar. Pero ya van dos veces seguidas que los toman por sorpresa
Dicho eso, la expresión “tomar una copia de Linux” resume de forma exagerada y simplista la enorme cantidad de trabajo que Red Hat hace para crear un lanzamiento de RHEL
Red Hat reúne cientos o miles de proyectos upstream para construir RHEL, participa en muchos de ellos, prueba todo en conjunto, ayuda a los socios a certificar software sobre esa base y hace muchas otras cosas
Es cierto que Red Hat no “posee” el kernel de Linux, pero durante mucho tiempo también ha contribuido enormemente a su desarrollo. RHEL ni siquiera es solo el kernel ni un único upstream. Es el resultado de probar miles de paquetes en conjunto y lanzarlos como un producto con soporte
Lo que Red Hat intenta proteger no es el código fuente de un proyecto concreto ni de varios proyectos, sino el valor que creó al unir todas esas piezas. Y casualmente, lo que empresas, competidores y comunidad quieren tampoco es el código fuente en sí, sino precisamente ese valor
Todos quieren en la práctica un snapshot de un momento específico sobre el cual todos acordaron como estándar de facto. Eso pasa porque toda la comunidad no ha logrado ponerse de acuerdo sobre otro estándar viable al que las aplicaciones puedan apuntar de forma amplia. Ese estándar tiene nombre: es RHEL, y es de Red Hat
Si quieres, puedes tomar todas las piezas y armarlas tú mismo. Pero nadie aparte de Red Hat tiene derecho a certificar eso como RHEL, ni oficial ni extraoficialmente
Si eso te molesta, de verdad recomiendo impulsar a Debian como el estándar que todos certifiquen como objetivo. O crear una empresa que supere a Red Hat y ocupe la posición que hoy tiene RHEL
Mark Shuttleworth pasó años criticando el modelo de negocio de RHEL de Red Hat, pero ahora, viendo Ubuntu Pro mover las actualizaciones de paquetes después de 5 años y cobrar por actualizaciones de los repositorios Universe y Main, parece que está haciendo algo bastante parecido
Oracle Linux, Alma Linux y Rocky Linux son todos downstream de RHEL
Puedes pasarte todo el día afirmando lo parecido que es CentOS Stream a RHEL. Puedes decir que para ti no es gran cosa que ahora sea upstream
Pero en la práctica, para muchos usuarios y empresas sí importa si algo es upstream o downstream
También importa que IBM esté intentando bloquear el acceso al código open source y restringir que los suscriptores no puedan redistribuir ese mismo código open source
IBM está causando un daño enorme al ecosistema open source del que se beneficia
La persona que escribió ese tuit soy yo
Mike, que fue quien señaló esto primero en Mastodon, acaba de actualizar su tuit, o mejor dicho, su toot, diciendo que su red de contactos en Red Hat le confirmó que esto es un bug
La suscripción para desarrolladores sigue limitada a 16 servidores
https://twitter.com/fareszr/status/1673145072714665984
RHEL tiene una gran ventaja en el ecosistema de drivers que quizá ni ellos mismos entienden del todo. Creo que corren el riesgo de arruinar eso
Cuando la industria empezó a tomarse Linux en serio, RHEL era la distribución dominante. Como resultado, por accidente RHEL y sus derivadas se convirtieron en el objetivo principal de los drivers comerciales para hardware
Por ejemplo, tarjetas de red de baja latencia poco conocidas o tarjetas de captura de paquetes son más fáciles de hacer funcionar en distribuciones derivadas de RHEL que en otros sistemas. Si hablas con las empresas que fabrican ese equipo, asumen a la familia RHEL como estándar por defecto
Gracias al soporte de drivers, las distribuciones derivadas de Red Hat se volvieron el estándar de las distribuciones comerciales. Pero Red Hat no fue quien se quedó con esa escala de despliegue. El volumen real de implementación está en CentOS/Rocky/Alma instalados en hedge funds, firmas de proprietary trading y grids de exploración petrolera
A mi parecer, esta situación de los drivers es el verdadero valor del ecosistema de Red Hat. El espacio de usuario está medio desordenado y el gestor de paquetes no impresiona. Aun así, se despliegan derivadas de RHEL porque los drivers funcionan sin demasiados problemas
Si Red Hat pudiera eliminar las distribuciones derivadas, desencadenaría un punto de inflexión en el que la industria dejaría de tratar a la familia RHEL como el objetivo estándar para drivers
Una empresa que usaba CentOS en 5,000 servidores no va a empezar de repente a pagar 350 dólares al año por servidor. Se va a pasar a Debian y va a aguantar el dolor de la transición. La cultura de los drivers comerciales también la seguiría rápido. Ese cambio cultural podría ocurrir en días, no en años
Me parece ingenuo el modelo de cobro por servidor de Red Hat. Con 350 dólares al año solo obtienes una licencia sin soporte. Habrá algo de ingresos en empresas pequeñas y en compañías con expectativas tradicionales de servicio, pero ¿de verdad ahí está la oportunidad?
Cuando montas un datacenter, quieres poder arrancar cada servidor por PXE. Así puedes cambiar la imagen del sistema para un grid creando una nueva imagen PXE y reiniciando los hosts. Tener esta configuración es engorroso, y sería bueno que Red Hat ofreciera una solución lista para usar bien hecha
Un modelo de 2,000 dólares al año por cada 100 servidores por sitio, incluyendo soporte real para PXE, serviría. Si Red Hat tomara ese camino, podría coexistir con las distribuciones derivadas. Si lo convirtieran en un appliance, podría volverse un producto tan común como un firewall o un switch de red
Tengo entendido que RHEL básicamente aplica parches sobre el mismo kernel sin cambiar mucho las interfaces. Por eso parecería que drivers en código fuente, o incluso algunos drivers en forma de blob binario, deberían compilar y funcionar casi igual que con un kernel general
Más allá de que los desarrolladores de drivers usen RHEL/CentOS y validen su funcionamiento ahí, ¿hay algo que se me esté escapando?
Lo más interesante fue el análisis legal de RHEL y la GPL de Software Freedom Conservancy que enlazó el OP
https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
Puedes usar código GPL de otra persona en un producto y cobrar dinero por ello. Si te lo piden, tienes que “publicar” el código fuente GPL y tu propio código derivado de código GPL. Aquí publicar significa dárselo a quien lo solicite, no que tengas que tener una página de descarga pública ni facilitarlo de forma sencilla
Puedes enviarlo en el medio que prefieran, como DVD o memoria flash, y puedes cobrar algo como el costo del medio. O sea, no hace falta que hagas fácil obtener el código fuente, ni que ofrezcas gratis el producto compilado
Hay muchas cosas que se pueden hacer dentro de los límites de la GPL. Si IBM/Red Hat se mantiene dentro de eso, ¿cuál sería el problema?
Esto también es posible sin la GPL. Por ejemplo, SQLite3 es de dominio público, pero existe el SQLite Consortium, y me imagino que le deja ingresos bastante buenos a D. R. Hipp y sus empleados. Casi no compite con forks porque hacer un fork confiable de SQLite3 es muy difícil, y la razón es que la mejor suite de pruebas es propietaria y secreta
Para las empresas, el open source es una herramienta. Para los individuos también lo es. Si eres una persona joven que recién empieza y tienes pocos recursos, puede servirte hacer software útil como open source para ganar reputación y conseguir mejores oportunidades laborales o la opción de arrancar un negocio propio
Los MBA de IBM por fin tomaron el control de Red Hat
Es el típico intento de exprimir aunque sea un dólar más, aunque a largo plazo les salga el tiro por la culata. Ya sabía que tarde o temprano iba a pasar, y la verdad me sorprende que haya tardado tanto
Es algo que se ve en muchas empresas hoy en día. Se arrancan proyectos que no van a ninguna parte o que pronto se cancelan, se pagan los bonos, la gente se va, y se repite el ciclo
Solo quedan como tontos quienes se quedan por la rentabilidad de largo plazo. Viéndolo al revés, tal vez los trabajadores por fin ya descubrieron el secreto de las empresas
Parece que esta decisión se tomó con mucha participación de personas con larga trayectoria. ¿Y si fuera cierto justamente lo contrario?
La frase de “ignoren también el hecho de que Red Hat construye productos sobre Linux, que ni creó ni posee” parece pasar por alto que una parte importante del éxito sostenido de Linux se debe a Red Hat
Red Hat tuvo mucho impacto al impulsar el cumplimiento normativo y financiar desarrollo alineado con eso, lo que permitió competir en contratos gubernamentales, y el desarrollo de Linux que Red Hat ha apoyado directamente también ha sido enorme
Claro, Red Hat no es la única razón del éxito de Linux, pero está claro que el éxito de RHEL jugó un papel importante para hacer que Linux fuera adecuado para el datacenter
Linux se volvió popular por medio del despliegue de base, y después las empresas empezaron a ganar dinero a partir de eso. Últimamente apareció una narrativa donde las empresas hablan como si hubieran puesto a girar la rueda desde el principio, pero eso no es cierto
Hay varias razones por las que Stream no puede ser un sustituto de la familia CentOS, es decir, de alternativas como Alma o Rocky
Primero, Stream no puede usarse como base para compilar paquetes compatibles con EL. No hay garantía de que Stream no rompa la compatibilidad ABI
Segundo, Stream no tiene un ciclo de soporte largo de varios años, así que no puede usarse como un sistema estable. Claro, no hace falta el soporte de licencia de pago de Red Hat, y sí hay una comunidad grande dispuesta a ayudar reportando bugs y haciendo pruebas
En sentido estricto, sí podría decirse que no hay garantía, pero una ruptura así también rompería futuras versiones de RHEL, así que sería un bug
El período de soporte es de 5 años
Apoyo al 100% y agradezco que cualquiera, incluido Jeff, tenga derecho a tomar una postura al decidir en qué usar su tiempo
El tiempo que se nos da es finito y, sobre todo cuando cambia lo que uno considera importante, también hay que usar ese tiempo en función de eso. El texto de Jeff, "Saying No", transmite muy bien por qué esto es importante
Lo que sí me cuesta entender es el uso excesivo de anécdotas relacionadas con IBM, las expresiones reformuladas de manera que Red Hat parezca haber hecho comentarios groseros a la comunidad, y la desfachatez necesaria para hacer afirmaciones como “díganles a los empleados que dejen de [hacer cierta acción]”
Entiendo que esto pudo haberse sentido como una ruptura de confianza, y que cuando se rompe la confianza probablemente es cuando más duele. Por eso también entiendo la reacción emocional
Pero, como mantenedor o contribuyente de código abierto, para reducir mucho más la carga cognitiva propia, probablemente habría sido mejor simplemente dejar de dar soporte y seguir adelante
https://www.jeffgeerling.com/blog/2022/just-say-no