#39 Me he movido por toda la costa este en tren con un Pass de 15 días y creo que me costó unos 120 dólares, es si no en business class.
#8 eran, ahora tienen el corral descontrolado.
#79 Pero es que en #10 dices RedHat está lleva bastante tiempo en esta línea, son los primeros en meter este tipo de cambios drásticos que rompen el sistema o cambiar el sistema por dentro para que se caiga a pedazos. Puedo entender que systemd solo funcione en Linux y que sus avances no lleguen a BSD, pero de ahí a que haya acciones de Red Hat u otros para "romper" o se "caiga a pedazos" hay un trecho largo.
Sobre cambios que funcionan sobre cada sistema operativo... ¿los avances del kernel como el nuevo módulo de NTFS entonces también te parecen mal? o eBPF? o BTRFS?
Hay muchas cosas que no serán compatibles y systemd es otra más. No es el fin del mundo y no hace que systemd sea peor ni rompa nada.
#91 Lo que llamas avances para mí son retrocesos que hacen el sistema más inestable. Cualquier cambio nuevo hace un sistema inestable y es lo que lleva Red Hat haciendo desde hace tiempo, introducir nuevos cambios que son solo para Linux y que rompen la forma de hacer las cosas según Unix. Es cortoplacismo que a largo tiempo se está viendo que es un error romper los estándares para introducir programas que solo sirven para el ecosistema Linux.
#93 estás monopolizando este hilo con chorradas, echando a perder lo que podría ser una discusión interesante.
Lo que llamas avances para mí son retrocesos que hacen el sistema más inestable. Cualquier cambio nuevo hace un sistema inestable
O sea, que no hay que cambiar nada. Por favor, deja a los profesionales.
#91 "Red Hat lleva haciendo esto desde hace 3 décadas: pagan las conferencias, hacen donaciones para proyectos y contratan a los desarrolladores que trabajan en dichos proyectos.
Así fue como Red Hat se hizo con la influencia de casi toda la pila de escritorios de Linux: GTK, Gnome, Flatpack, Wayland, Systemd, Pulseaudio y muchas otras piezas fundamentales de software tienen su proceso de desarrollo controlado por empleados de Red Hat." https://news.ycombinator.com/item?id=32024548
Traducción realizada con la versión gratuita del traductor www.DeepL.com/Translator
#163 Goto #151 Qué curiosidad que todo lo relacionado con "Linux en el escritorio" esté controlado durante las últimas décadas por Red Hat (que ahora es IBM): "GTK, Gnome, Flatpack, Wayland, Systemd, Pulseaudio y muchas otras piezas fundamentales de software tienen su proceso de desarrollo controlado por empleados de Red Hat." Qué raro que en Linux no haya un escritorio como el de MacOS que le haga sombra al escritorio de Windows. Por supuesto que era esencial que el escritorio en Linux sea deficiente y ahora con Systemd, Wayland, etc añaden más inestabilidad al escritorio que es lo que echa al usuario común, cuando algo básico simplemente no funciona o deja de funcionar, porque ahora se encarga Systemd de que funcione y todavía no está muy fino.
#164 Menuda sarta de estupideces. Es normal que la mayor empresa dentro del mundo Linux lidere muchos proyectos con profesionales. Lo raro sería que aficionados con dedicación pulsante lideraran algún gran proyecto.
Lo de la "inestabilidad al escritorio" me da un poco la risa. El fraccionamiento, los múltiples y diversas visiones dentro de la multitud de integrantes y las luchas entre estúpidos fanboys han impedido que haya una dirección única, esparciéndose los esfuerzos, y generando la actual situación donde cada unidad reimplementa la rueda pero solo para ellos.
Curiosamente systemd me parece un camino que han tomado muchos y que puede empezar a disminuir parte del fraccionamiento en Linux.
Si crees que systemd no "está fino" es porque no te has dignado a usarlo.
Resumiendo, todos tus comentarios me parecen una pataleta de fanboy que no ha razonado sipuiera sobre la realidad, y que se encarga de extraer impresiones de otros como propia.
En el mundo real (me refiero al mío, no al de las pajas mentales) systemd es el estándar linux de facto, y esperemos que Wayland y muchas otras piezas también lleguen a serlo, para que tengamos un Linux (GNU/Linux para los pedantes) más robusto y sin el marasmo de incompatibilidades que tenemos incluso entre distribuciones muy cercanas.
#165 No, si estoy de acuerdo, por supuesto que Systemd es un estandar de Linux y es de código abierto. Pero yo soy más de Unix y en ese aspecto soy más conservador. El día que para usar una distro tenga que usar Systemd por cojones, pues ya formateo definitivamente la partición. Como hice con Windwos en su día. En el trabajo uso lo que haya pero en mi ordenador pongo lo que me da la gana y Systemd no existe.
Como Google, que ahora ha decidido que leer el gmail a través del cliente de consola Alpine es "inseguro", pues un servicio menos que uso.
#166 ¿Más de unix? Aparte de los sabores de BSD (licencia BSD), y alguno comercial (¿queda algo vivo aparte que AIX?), no se que usarás. Y si eres más de GPL 
Por cierto, si eres más de Unix ¿eres de BSD o de System V?, ¿pones todo en runlevels?, ¿en el inittab?, ¿en un .sh donde pones los servicios a arrancar?
Más de Unix
En el resto que cuentas suenas a un neo talibán de no se qué, un neoludita que no acepta la evolución, sigo pensando que hacia un sitio mejor.
#168 MacOS es oficialmente UNIX (no lo uso). Luego uso OpenBSD y varios GNU sin Systemd, principalmente Devuan https://www.devuan.org Me interesa también Plan9, http://9legacy.org lo tengo en un par de equipos. No es UNIX pero son de la misma escuela y salió del mismo sitio de donde salió UNIX. Y por supuesto soy más de GNU que de Linux, mas de Stallman que de open source.
#165 Lo raro sería que aficionados con dedicación pulsante lideraran algún gran proyecto. Esta siempre ha sido la mayor mentira dentro del software libre y de Linix en particular, que está desarrollo por "aficionados" en su tiempo libre, cuando siempre han sido proyectos de universidades, empresas, fundaciones y distintas compañías. También es cierto que hay programas sin financiación y ese siempre ha sido uno de los problemas del software libre, que no pagan salarios por lo que es gratis. Con la GPL al menos el código queda abierto, pero con las licencias MIT, está todo vendido.
#74 Fedora es más que una distro de pruebas, si bien es una distro ideal para adoptar y probar nuevas tecnologías. Pero en base a tu comentario en #10 ¿crees que Fedora rompe GNU/Linux?
AWS ha decido usar Fedora como base para su Amazon Linux. ¿Crees que esta gente también quiere ver GNU/Linux cayéndose a pedazos?
#79 Pero es que en #10 dices RedHat está lleva bastante tiempo en esta línea, son los primeros en meter este tipo de cambios drásticos que rompen el sistema o cambiar el sistema por dentro para que se caiga a pedazos. Puedo entender que systemd solo funcione en Linux y que sus avances no lleguen a BSD, pero de ahí a que haya acciones de Red Hat u otros para "romper" o se "caiga a pedazos" hay un trecho largo.
Sobre cambios que funcionan sobre cada sistema operativo... ¿los avances del kernel como el nuevo módulo de NTFS entonces también te parecen mal? o eBPF? o BTRFS?
Hay muchas cosas que no serán compatibles y systemd es otra más. No es el fin del mundo y no hace que systemd sea peor ni rompa nada.
#91 Lo que llamas avances para mí son retrocesos que hacen el sistema más inestable. Cualquier cambio nuevo hace un sistema inestable y es lo que lleva Red Hat haciendo desde hace tiempo, introducir nuevos cambios que son solo para Linux y que rompen la forma de hacer las cosas según Unix. Es cortoplacismo que a largo tiempo se está viendo que es un error romper los estándares para introducir programas que solo sirven para el ecosistema Linux.
#93 estás monopolizando este hilo con chorradas, echando a perder lo que podría ser una discusión interesante.
Lo que llamas avances para mí son retrocesos que hacen el sistema más inestable. Cualquier cambio nuevo hace un sistema inestable
O sea, que no hay que cambiar nada. Por favor, deja a los profesionales.
#91 "Red Hat lleva haciendo esto desde hace 3 décadas: pagan las conferencias, hacen donaciones para proyectos y contratan a los desarrolladores que trabajan en dichos proyectos.
Así fue como Red Hat se hizo con la influencia de casi toda la pila de escritorios de Linux: GTK, Gnome, Flatpack, Wayland, Systemd, Pulseaudio y muchas otras piezas fundamentales de software tienen su proceso de desarrollo controlado por empleados de Red Hat." https://news.ycombinator.com/item?id=32024548
Traducción realizada con la versión gratuita del traductor www.DeepL.com/Translator
#163 Goto #151 Qué curiosidad que todo lo relacionado con "Linux en el escritorio" esté controlado durante las últimas décadas por Red Hat (que ahora es IBM): "GTK, Gnome, Flatpack, Wayland, Systemd, Pulseaudio y muchas otras piezas fundamentales de software tienen su proceso de desarrollo controlado por empleados de Red Hat." Qué raro que en Linux no haya un escritorio como el de MacOS que le haga sombra al escritorio de Windows. Por supuesto que era esencial que el escritorio en Linux sea deficiente y ahora con Systemd, Wayland, etc añaden más inestabilidad al escritorio que es lo que echa al usuario común, cuando algo básico simplemente no funciona o deja de funcionar, porque ahora se encarga Systemd de que funcione y todavía no está muy fino.
#164 Menuda sarta de estupideces. Es normal que la mayor empresa dentro del mundo Linux lidere muchos proyectos con profesionales. Lo raro sería que aficionados con dedicación pulsante lideraran algún gran proyecto.
Lo de la "inestabilidad al escritorio" me da un poco la risa. El fraccionamiento, los múltiples y diversas visiones dentro de la multitud de integrantes y las luchas entre estúpidos fanboys han impedido que haya una dirección única, esparciéndose los esfuerzos, y generando la actual situación donde cada unidad reimplementa la rueda pero solo para ellos.
Curiosamente systemd me parece un camino que han tomado muchos y que puede empezar a disminuir parte del fraccionamiento en Linux.
Si crees que systemd no "está fino" es porque no te has dignado a usarlo.
Resumiendo, todos tus comentarios me parecen una pataleta de fanboy que no ha razonado sipuiera sobre la realidad, y que se encarga de extraer impresiones de otros como propia.
En el mundo real (me refiero al mío, no al de las pajas mentales) systemd es el estándar linux de facto, y esperemos que Wayland y muchas otras piezas también lleguen a serlo, para que tengamos un Linux (GNU/Linux para los pedantes) más robusto y sin el marasmo de incompatibilidades que tenemos incluso entre distribuciones muy cercanas.
#165 No, si estoy de acuerdo, por supuesto que Systemd es un estandar de Linux y es de código abierto. Pero yo soy más de Unix y en ese aspecto soy más conservador. El día que para usar una distro tenga que usar Systemd por cojones, pues ya formateo definitivamente la partición. Como hice con Windwos en su día. En el trabajo uso lo que haya pero en mi ordenador pongo lo que me da la gana y Systemd no existe.
Como Google, que ahora ha decidido que leer el gmail a través del cliente de consola Alpine es "inseguro", pues un servicio menos que uso.
#165 Lo raro sería que aficionados con dedicación pulsante lideraran algún gran proyecto. Esta siempre ha sido la mayor mentira dentro del software libre y de Linix en particular, que está desarrollo por "aficionados" en su tiempo libre, cuando siempre han sido proyectos de universidades, empresas, fundaciones y distintas compañías. También es cierto que hay programas sin financiación y ese siempre ha sido uno de los problemas del software libre, que no pagan salarios por lo que es gratis. Con la GPL al menos el código queda abierto, pero con las licencias MIT, está todo vendido.
#43 systemd es mucho más que el sistema de arranque y ya lo era en 2012.
No hay ningún proxy war entre Red Hat y Canonical, el problema es que upstartd tenía limitaciones que se solucionaron tomando otro camino. Red Hat usaba upstartd en RHEL6, no era ajeno a la tecnología.
Que algo que use Red Hat y su familia se convierta en estándar de facto muchas veces pasa no por posición dominante si no por colaboración con la comunidad. Si la comunidad no quiere, como es el caso de Devuan, no se usa.
#10 una empresa que factura más de 4.000 millones de dolares al año te crees que va a romper GNU/Linux para que se caiga a pedazos?
¿En serio crees que Red Hat, que tiene millones de instalaciones de RHEL en producción, tiene interés en que su producto estrella (RHEL) durante los últimos casi 20 años no funcione de la mejor manera posible?
#74 Fedora es más que una distro de pruebas, si bien es una distro ideal para adoptar y probar nuevas tecnologías. Pero en base a tu comentario en #10 ¿crees que Fedora rompe GNU/Linux?
AWS ha decido usar Fedora como base para su Amazon Linux. ¿Crees que esta gente también quiere ver GNU/Linux cayéndose a pedazos?
#79 Pero es que en #10 dices RedHat está lleva bastante tiempo en esta línea, son los primeros en meter este tipo de cambios drásticos que rompen el sistema o cambiar el sistema por dentro para que se caiga a pedazos. Puedo entender que systemd solo funcione en Linux y que sus avances no lleguen a BSD, pero de ahí a que haya acciones de Red Hat u otros para "romper" o se "caiga a pedazos" hay un trecho largo.
Sobre cambios que funcionan sobre cada sistema operativo... ¿los avances del kernel como el nuevo módulo de NTFS entonces también te parecen mal? o eBPF? o BTRFS?
Hay muchas cosas que no serán compatibles y systemd es otra más. No es el fin del mundo y no hace que systemd sea peor ni rompa nada.
#91 Lo que llamas avances para mí son retrocesos que hacen el sistema más inestable. Cualquier cambio nuevo hace un sistema inestable y es lo que lleva Red Hat haciendo desde hace tiempo, introducir nuevos cambios que son solo para Linux y que rompen la forma de hacer las cosas según Unix. Es cortoplacismo que a largo tiempo se está viendo que es un error romper los estándares para introducir programas que solo sirven para el ecosistema Linux.
#93 estás monopolizando este hilo con chorradas, echando a perder lo que podría ser una discusión interesante.
Lo que llamas avances para mí son retrocesos que hacen el sistema más inestable. Cualquier cambio nuevo hace un sistema inestable
O sea, que no hay que cambiar nada. Por favor, deja a los profesionales.
#91 "Red Hat lleva haciendo esto desde hace 3 décadas: pagan las conferencias, hacen donaciones para proyectos y contratan a los desarrolladores que trabajan en dichos proyectos.
Así fue como Red Hat se hizo con la influencia de casi toda la pila de escritorios de Linux: GTK, Gnome, Flatpack, Wayland, Systemd, Pulseaudio y muchas otras piezas fundamentales de software tienen su proceso de desarrollo controlado por empleados de Red Hat." https://news.ycombinator.com/item?id=32024548
Traducción realizada con la versión gratuita del traductor www.DeepL.com/Translator
#163 Goto #151 Qué curiosidad que todo lo relacionado con "Linux en el escritorio" esté controlado durante las últimas décadas por Red Hat (que ahora es IBM): "GTK, Gnome, Flatpack, Wayland, Systemd, Pulseaudio y muchas otras piezas fundamentales de software tienen su proceso de desarrollo controlado por empleados de Red Hat." Qué raro que en Linux no haya un escritorio como el de MacOS que le haga sombra al escritorio de Windows. Por supuesto que era esencial que el escritorio en Linux sea deficiente y ahora con Systemd, Wayland, etc añaden más inestabilidad al escritorio que es lo que echa al usuario común, cuando algo básico simplemente no funciona o deja de funcionar, porque ahora se encarga Systemd de que funcione y todavía no está muy fino.
Lennart es un personaje interesante. Poca gente puede decir que 3 de sus contribuciones han terminado en el sistemas de casi todos los usuarios de escritorio de Linux (avahi, pulseaudio y systemd) y en casi todos los servidores Linux (systemd).
Es una persona que ha tenido que aguantar amenazas de muerte, difamaciones y burlas. Y a cambio ha mejorado y mucho el panorama de Linux.
#6 muchas distros lo adoptaron para 2012, eso es hace 10 años. Incluso Debian y Ubuntu empezaron a adoptarlo en 2012 y es el por defecto desde 2015 (+7 años!).
https://en.wikipedia.org/wiki/Systemd#Adoption
#21 qué tendrá que ver Red Hat en que sistema de arranque usa Debian!? Debian tuvo su propio debate interno y salió a favor de systemd.
https://lwn.net/Articles/452865/
#38 System V era el sistema tradicional de Unix. El consenso era que estaba ya obsoleto, pero reemplazarlo se volvió una guerra de proxies estre Red Hat y Canonical por ver quién controlaba la tecnología de arranque. En el artículo que enlazas lo resumen. Al final, debian tiene el suficiente peso dentro del mundo Linux como para qur rl sostema de arranque que ellos elijan se vuelva el estándar de facto, tal como ocurrió.
#43 systemd es mucho más que el sistema de arranque y ya lo era en 2012.
No hay ningún proxy war entre Red Hat y Canonical, el problema es que upstartd tenía limitaciones que se solucionaron tomando otro camino. Red Hat usaba upstartd en RHEL6, no era ajeno a la tecnología.
Que algo que use Red Hat y su familia se convierta en estándar de facto muchas veces pasa no por posición dominante si no por colaboración con la comunidad. Si la comunidad no quiere, como es el caso de Devuan, no se usa.
#43 Mira, al final la controla Microsoft ...
#67 Es muy probable que siempre haya trabajado para Microsoft... aunque durante un tiempo le haya pagado la nómina Red Hat.
Otra de sus creaciones es pulseaudio... otro software con el que a menudo hubo mucha controversia.
Desde hace poco ya se puede usar pipewire y muchos usuarios ya lo están instalando en lugar de pulseaudio.
#111 Para lo que yo uso el audio en mis computadoras, siempre me sirvió ALSA.
Hace años que en muchos foros se reportaban problemas con pulseaudio, después parece que mejoró algo. Sin embargo, a día de hoy, mucha gente que conozco entra los que graban vídeos para Youtube prefieren pipewire.
#139 Si, pipewire es mejor que pulseaudio. Es mucho mas nuevo y ha aprendido algunas lecciones de pulseaudio, sin duda.
Y pulseaudio es MUCHO mejor que alsa.
Haces mucha videoconferencia? Yo si. Y con alsa tenia continuamente problemas porque el dispositivo lo pillaba un programa y no lo podia usar otro.
Si conectaba unos cascos o una webcam externa con micro, era una loteria saber por donde iba a salir el sonido, si es que salia. Y si los desconectaba, lo mismo. Tampoco podia controlar el volumen por aplicacion, ni silenciar una aplicacion completamente.
Con pulseaudo hago click en el control de volumen y controlo todo eso. Enciendo los cascos bluetooth en medio de una llamada y voila, el audio sale por ahi. Envio el audio de mi movil a mi portatil en un par de clicks.
Asi que el hecho de que A TI te sirviera ALSA es del todo irrelevante.
#61 te presento la Y Vasca: https://es.wikipedia.org/wiki/Y_vasca
Vale, algún día se conectara con Castilla (2030 con suerte) y con Francia (2038 como pronto), pero no lo tengo yo tan claro. https://www.eldiario.es/euskadi/tren-alta-velocidad-avanza-lento-euskadi-viaje-34-anos-ver-estacion-final_130_8055921.html
#111 yo también dudo que el resto seamos de la misma especie que tú
#48 Existen distintas vacunas, pero disponibles, hoy por hoy, las pocas que llegan.
#6 añado dirección https://github.com/AltraMayor/f3
me ha venido muy bien alguna vez, gran herramienta
#54 pues agradecería que me encontraras algún link de paquetes desaparecidos que no sea que estén en PowerTools, EPEL o que no son parte de RHEL8. PowerTools se mantiene desde CentOS, EPEL desde Fedora y lo que no es parte de RHEL8 se decide en RH. Con lo que CentOS so lo podría liarla en BaseOS, AppStream o PowerTools.
> Ceph no es the RH. Ni siquiera aparece mencionado dentro de los contributors: en.wikipedia.org/wiki/Ceph_(software)
RH compró Inktank, que era la principal empresa tras Ceph y fundada por su creador Sage Weil, en 2014. Ceph no es de la comunidad, pero la compañía con mayor peso tras Ceph es Red Hat y tiene dos productos basados en Ceph: Red Hat Ceph https://www.redhat.com/en/technologies/storage/ceph y OpenShift Container Storage 4 https://www.openshift.com/blog/openshift-container-storage-4-introduction-to-ceph
Puedes ver también el peso de Red Hat en los commits (+60%): https://www.stackalytics.com/unaffiliated?project_type=ceph-group (Sage a veces hacía commits con su viejo mail de DreamHost)
> Eso lo piensas tú sin ninguna argumentación.
Va más allá de un pensamiento, pero no puedo publicar material bajo NDA.
> Si tanto sabes dame otro motivo porque no le encuentro otro.
Hay muchos motivos, pero por NDA tampoco puedo publicarlos.
A mi me duele que no se haya comunicado mejor o incluso que los nombres son liosos. Llamaría a CentOS Stream $otracosa y dejaría CentOS para que lo maneje la comunidad si la hubiera y pudiera hacer adelante con los gastos y demás.
La parte buena es que se ha avisado con suficiente antelación para que se pueda organizar una alternativa. Habrá que ver como se cocina esta, quien lo lleva y cuanta gente se mueve.
#55 no sé de ceph pero parece un caso similar a ansible... espero que no se corrumpa el projecto desde rh.
Bien, entiendo que tengas un nda y que puedan existir otras razones, pero no son para nada aparentes. No parece tener lógica y está siendo muy mal recibido por empresas y comunidad.
Dónde se ha anunciado "con suficiente antelación"? La primera noticia no tiene ni una semana.
La última vez que miré CentOS 8 iba a durar unos buenos años y de repente anuncian un EOL para un año ! Esto ha sentado como una patada. Nada serio.
#51
> Sin tan sencillo crees que es pues hazlo tú.
Yo me dedico a cosas en Fedora y EPEL, podría decirse que ya aporto mi granito de arena a ese 'si es tan sencillo hazlo tú'.
> Ten en cuenta que en realidad se trata de un grupo minúsculo de gente que hace esto en sus ratos libres.
Y ahí está uno de los peligros de CentOS, si no hay comunidad suficiente no hay garantías de que salga el proyecto adelante. Es lo que se vio en CentOS-6, lo que se mejoró en CentOS-7 pero que ha decaído otra vez en CentOS-8.
> Para mi Centos Stream no tiene razón de ser. Ya existe Fedora desde hace muchos años para probar lo que va a ser la siguiente release de RHEL.
Tiene mucha razón de ser. Fedora saca una versión cada 6 meses y RHEL sale cada 5 años. RHEL no sale del último Fedora. Por ejemplo, Fedora 34 saldrá en ~2021-04 y RHEL9 será sobre ~2022-05 y se basará en Fedora 34. Es decir, para cuando salga RHEL9 Fedora estará en la versión 36.
Ahora planteate que tienes un producto que tiene que funcionar en RHEL9 y que tiene que estar listo para el día que RHEL9 sea GA. Como lo haces? Lo pruebas en Fedora 34, que está sin soporte y que no tiene otros cambios que se hayan hecho sobre RHEL? O lo pruebas en CentOS Stream, que será donde irá aterrizando todo el cambio antes de la GA y será lo más parecido que hay con RHEL9?
Aplica esto por ejemplo a GitHub Actions o Travis o lo que quieras, donde quieres tener un CI de validación de lo que estas programando. Esperas hasta que sea GA y luego de golpe tienes que hacer todos los cambios o vas adaptando según se vaya estabilizando?
O por ejemplo, si estas trabajando en certificar algo cuando 9.0 sea GA pero por fechas es más lógico certificar en 9.1, ¿qué haces? certificas en 9.0 y luego otra vez en 9.1? O vas adelantando trabajo y lo pruebas en CentOS Stream 9.1? Que esto es básicamente lo que estaba pidiendo Intel para sus drivers por ejemplo.
Y recuerda, CentOS Stream tendrá su rama de versión 8 y su rama de versión 9, no será siempre la upstream de RHEL.
#53
> Yo me dedico a cosas en Fedora y EPEL,
Perfecto. Ya somos dos que aportan a la comunidad
> ...pero que ha decaído otra vez en CentOS-8
La gente suele crecer, tener familia y otras obligaciones. Si la cosa rueda, se deja rodar.
Ahora la comunidad ha reaccionado bien fuerte. Veremos lo que pasa pero Rocky el repo con más tendencia en github.
> Tiene mucha razón de ser.
Bien, Te acepto que haya empresas interesadas en tener una versión previa más fresca de RHEL. Pues llámalo RHEL Stream, o CentOS Stream.
El problema ha surgido de la decisión de terminar con CentOS "downstream", que fue el motivo de CentOS y el de Scientific Linux y el de muchos más. Una distro estable profesional y libre.
No se trata de evitar pagar a RH, la gran mayoría de empresas usan CentOS en test y RH en production o un mix. Se trata de proveer un punto de partida a estudiantes, empresas, organizaciones que no pueden permitirse o no necesitan del soporte de RH.
Es una pena que CentOS pierda su razón de ser. Pero no pasa nada, surgirán otros clones. La licencia GPL protege al software libre para que siga siendo libre.
#50
> forums.centos.org/viewtopic.php?t=72120
En el mismo foro explican que a) o están en el repo de PowerTools o que estarán en EPEL, pero EPEL8 para 8 tardó muchos meses en publicarse por problemas técnicos, no por ocultismo.
> bugs.centos.org/view.php?id=16626
En el tercer comment explican que o están en PowerTools o que son paquetes que no existen en RHEL8, y por tanto tampoco en CentOS8 https://bugs.centos.org/view.php?id=16626#c37175
Por tanto tu comentario de "desaparecieron algunos paquetes del repo" es incorrecto, Red Hat no ha quitado ningún paquete de CentOS de manera malintencionada ni nada por el estilo, o están en PowerTools, o están en EPEL o no están en RHEL/CentOS-8.
> El problema es que RH era una empresa que se dedicaba a crear una distro y documentación y las ganancias venían por el soporte profesional.
Y lo sigue siendo. Pero además ha crecido y tiene otros productos interesantes como OpenShift o Ceph.
> Parece que IBM no entiende del todo este modelo de negocio. No sabe lo que ha comprado y en lugar de hacerlo crecer corre el peligro de destruirlo.
IBM no tiene nada que ve en esta decisión.
#52 No tengo tiempo de buscarte más pero ha sido un problema que se ha repetido varias veces, y no parece descuido porque han sido unos cuantos paquetes -devel. Algunos movidos a EPEL, otros a powertools, otros simplemente desaparecidos.
Desconozco si ha sido premeditado, parte de una limpieza o puro despiste. Pero ha sido raro y un incordio para muchas empresas.
https://bugs.centos.org/view.php?id=17032
https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F
> tiene otros productos interesantes como OpenShift o Ceph.
Ceph no es the RH. Ni siquiera aparece mencionado dentro de los contributors: https://en.wikipedia.org/wiki/Ceph_(software)
> IBM no tiene nada que ve en esta decisión.
Eso lo piensas tú sin ninguna argumentación.
Yo he expuesto un motivo posible de parar de distribuir Centos "classic" (downstream) y cambiar a Centos upstream. IBM se ha gastado una pasta en la compra de RH el año pasado y quiere forzar a los usuarios de CentOS a pasarse a RHEL. Porque claramente, pocas empresas quieren tener producción en un upstream (en un banco de pruebas hablando claro), sin ningún tipo de estabilidad.
Si tanto sabes dame otro motivo porque no le encuentro otro.
Yo he promovido el binomio CentOS/RH en las empresas en las que he trabajado. Ahora me lo voy a pensar.
#54 pues agradecería que me encontraras algún link de paquetes desaparecidos que no sea que estén en PowerTools, EPEL o que no son parte de RHEL8. PowerTools se mantiene desde CentOS, EPEL desde Fedora y lo que no es parte de RHEL8 se decide en RH. Con lo que CentOS so lo podría liarla en BaseOS, AppStream o PowerTools.
> Ceph no es the RH. Ni siquiera aparece mencionado dentro de los contributors: en.wikipedia.org/wiki/Ceph_(software)
RH compró Inktank, que era la principal empresa tras Ceph y fundada por su creador Sage Weil, en 2014. Ceph no es de la comunidad, pero la compañía con mayor peso tras Ceph es Red Hat y tiene dos productos basados en Ceph: Red Hat Ceph https://www.redhat.com/en/technologies/storage/ceph y OpenShift Container Storage 4 https://www.openshift.com/blog/openshift-container-storage-4-introduction-to-ceph
Puedes ver también el peso de Red Hat en los commits (+60%): https://www.stackalytics.com/unaffiliated?project_type=ceph-group (Sage a veces hacía commits con su viejo mail de DreamHost)
> Eso lo piensas tú sin ninguna argumentación.
Va más allá de un pensamiento, pero no puedo publicar material bajo NDA.
> Si tanto sabes dame otro motivo porque no le encuentro otro.
Hay muchos motivos, pero por NDA tampoco puedo publicarlos.
A mi me duele que no se haya comunicado mejor o incluso que los nombres son liosos. Llamaría a CentOS Stream $otracosa y dejaría CentOS para que lo maneje la comunidad si la hubiera y pudiera hacer adelante con los gastos y demás.
La parte buena es que se ha avisado con suficiente antelación para que se pueda organizar una alternativa. Habrá que ver como se cocina esta, quien lo lleva y cuanta gente se mueve.
#55 no sé de ceph pero parece un caso similar a ansible... espero que no se corrumpa el projecto desde rh.
Bien, entiendo que tengas un nda y que puedan existir otras razones, pero no son para nada aparentes. No parece tener lógica y está siendo muy mal recibido por empresas y comunidad.
Dónde se ha anunciado "con suficiente antelación"? La primera noticia no tiene ni una semana.
La última vez que miré CentOS 8 iba a durar unos buenos años y de repente anuncian un EOL para un año ! Esto ha sentado como una patada. Nada serio.
Este post explica bastante bien lo que es CentOS Stream https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/
Stream no es nuevo, lleva unos meses existiendo para solucionar el problema que se vio al publicar RHEL8, que era que hasta que no se publica RHEL8 y luego CentOS8 no hay manera de probar integraciones, hacer CI upstream, preparar etc.
En CentOS Stream van a trabajar los mismos ingenieros que trabajan en RHEL, no es algo raro ni esperpéntico.
#32 tan tan saludable como que la comunidad de CentOS tardó 247 días en publicar CentOS-6. RH se hizo con CentOS para garantizar que había una continuidad y garantizar que CentOS-7 no corría peligro (27 días en publicarse tras RHEL-7). Pero otra vez se vio en problemas con CentOS-8 (140 días) debido a muchos cambios que se han hecho en RHEL8 (modularidad o el CI que era interno desde 2017).
CentOS no puede empezar a trabajar hasta que RHEL se publique, lo cual es un bloqueo grande. De hecho ahí nace Stream, para dar solución al vacío que hay hasta que RHEL se publica. Ahora RH ha decidido apostar por CentOS Stream en vez de CentOS. Hay mil razones, pero IBM no es una.
#46 Sin tan sencillo crees que es pues hazlo tú.
Ten en cuenta que en realidad se trata de un grupo minúsculo de gente que hace esto en sus ratos libres.
Para mi Centos Stream no tiene razón de ser. Ya existe Fedora desde hace muchos años para probar lo que va a ser la siguiente release de RHEL.
Yo he descrito una posible razón de cambiar el espíritu de CentOS (downstream) a CentOS Stream (upstream) y las consecuencias para las empresas. CentOS era una puerta de entrada a RH y ahora va a ser una de salida.
Ahora descríbeme tú los beneficios de CentOS y las razones/estrategia de IBM desde tu punto de vista.
#51
> Sin tan sencillo crees que es pues hazlo tú.
Yo me dedico a cosas en Fedora y EPEL, podría decirse que ya aporto mi granito de arena a ese 'si es tan sencillo hazlo tú'.
> Ten en cuenta que en realidad se trata de un grupo minúsculo de gente que hace esto en sus ratos libres.
Y ahí está uno de los peligros de CentOS, si no hay comunidad suficiente no hay garantías de que salga el proyecto adelante. Es lo que se vio en CentOS-6, lo que se mejoró en CentOS-7 pero que ha decaído otra vez en CentOS-8.
> Para mi Centos Stream no tiene razón de ser. Ya existe Fedora desde hace muchos años para probar lo que va a ser la siguiente release de RHEL.
Tiene mucha razón de ser. Fedora saca una versión cada 6 meses y RHEL sale cada 5 años. RHEL no sale del último Fedora. Por ejemplo, Fedora 34 saldrá en ~2021-04 y RHEL9 será sobre ~2022-05 y se basará en Fedora 34. Es decir, para cuando salga RHEL9 Fedora estará en la versión 36.
Ahora planteate que tienes un producto que tiene que funcionar en RHEL9 y que tiene que estar listo para el día que RHEL9 sea GA. Como lo haces? Lo pruebas en Fedora 34, que está sin soporte y que no tiene otros cambios que se hayan hecho sobre RHEL? O lo pruebas en CentOS Stream, que será donde irá aterrizando todo el cambio antes de la GA y será lo más parecido que hay con RHEL9?
Aplica esto por ejemplo a GitHub Actions o Travis o lo que quieras, donde quieres tener un CI de validación de lo que estas programando. Esperas hasta que sea GA y luego de golpe tienes que hacer todos los cambios o vas adaptando según se vaya estabilizando?
O por ejemplo, si estas trabajando en certificar algo cuando 9.0 sea GA pero por fechas es más lógico certificar en 9.1, ¿qué haces? certificas en 9.0 y luego otra vez en 9.1? O vas adelantando trabajo y lo pruebas en CentOS Stream 9.1? Que esto es básicamente lo que estaba pidiendo Intel para sus drivers por ejemplo.
Y recuerda, CentOS Stream tendrá su rama de versión 8 y su rama de versión 9, no será siempre la upstream de RHEL.
#53
> Yo me dedico a cosas en Fedora y EPEL,
Perfecto. Ya somos dos que aportan a la comunidad
> ...pero que ha decaído otra vez en CentOS-8
La gente suele crecer, tener familia y otras obligaciones. Si la cosa rueda, se deja rodar.
Ahora la comunidad ha reaccionado bien fuerte. Veremos lo que pasa pero Rocky el repo con más tendencia en github.
> Tiene mucha razón de ser.
Bien, Te acepto que haya empresas interesadas en tener una versión previa más fresca de RHEL. Pues llámalo RHEL Stream, o CentOS Stream.
El problema ha surgido de la decisión de terminar con CentOS "downstream", que fue el motivo de CentOS y el de Scientific Linux y el de muchos más. Una distro estable profesional y libre.
No se trata de evitar pagar a RH, la gran mayoría de empresas usan CentOS en test y RH en production o un mix. Se trata de proveer un punto de partida a estudiantes, empresas, organizaciones que no pueden permitirse o no necesitan del soporte de RH.
Es una pena que CentOS pierda su razón de ser. Pero no pasa nada, surgirán otros clones. La licencia GPL protege al software libre para que siga siendo libre.
#16 "desaparecieron algunos paquetes del repo y dejaron de publicar algunas de las herramientas de creación de los paquetes.", como no des ejemplos es pura falacia.
"pero RH está obligado por las licencias GPL a publicar los paquetes (que no son suyos) y cualquier modificación.", no es correcto. Está obligado por la GPL a facilitar las modificaciones realizadas si se solicitan por alguien que haya comprado los binarios. RH en cambio publica, y seguirá publicando según el FAQ, el código en formato SRPM de los paquetes de RHEL.
#45 Ninguna falacia, solo tienes que buscar un poco para ver que ha habido muchas discusiones al respecto.
https://forums.centos.org/viewtopic.php?t=72120
https://bugs.centos.org/view.php?id=16626
La afirmación sigue siendo correcta. Gracias a la GPL, RH tiene que facilitar el source de RHEL con la modificaciones de los paquetes GPL. Muy bien por RH que publica los srpm. Si eso cambia en el futuro, gracias a GPL cualquiera puede adquirir RHEL, solicitar el source de las modificaciones y publicarlas. Y ya está.
El problema es que RH era una empresa que se dedicaba a crear una distro y documentación y las ganancias venían por el soporte profesional. Parece que IBM no entiende del todo este modelo de negocio. No sabe lo que ha comprado y en lugar de hacerlo crecer corre el peligro de destruirlo.
Y yo era un fan de RH que he promovido CentOS/RHEL en todas las empresas donde he estado. Ahora estoy pensando si mover pieza o no. De momento espero.
#50
> forums.centos.org/viewtopic.php?t=72120
En el mismo foro explican que a) o están en el repo de PowerTools o que estarán en EPEL, pero EPEL8 para 8 tardó muchos meses en publicarse por problemas técnicos, no por ocultismo.
> bugs.centos.org/view.php?id=16626
En el tercer comment explican que o están en PowerTools o que son paquetes que no existen en RHEL8, y por tanto tampoco en CentOS8 https://bugs.centos.org/view.php?id=16626#c37175
Por tanto tu comentario de "desaparecieron algunos paquetes del repo" es incorrecto, Red Hat no ha quitado ningún paquete de CentOS de manera malintencionada ni nada por el estilo, o están en PowerTools, o están en EPEL o no están en RHEL/CentOS-8.
> El problema es que RH era una empresa que se dedicaba a crear una distro y documentación y las ganancias venían por el soporte profesional.
Y lo sigue siendo. Pero además ha crecido y tiene otros productos interesantes como OpenShift o Ceph.
> Parece que IBM no entiende del todo este modelo de negocio. No sabe lo que ha comprado y en lugar de hacerlo crecer corre el peligro de destruirlo.
IBM no tiene nada que ve en esta decisión.
#52 No tengo tiempo de buscarte más pero ha sido un problema que se ha repetido varias veces, y no parece descuido porque han sido unos cuantos paquetes -devel. Algunos movidos a EPEL, otros a powertools, otros simplemente desaparecidos.
Desconozco si ha sido premeditado, parte de una limpieza o puro despiste. Pero ha sido raro y un incordio para muchas empresas.
https://bugs.centos.org/view.php?id=17032
https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F
> tiene otros productos interesantes como OpenShift o Ceph.
Ceph no es the RH. Ni siquiera aparece mencionado dentro de los contributors: https://en.wikipedia.org/wiki/Ceph_(software)
> IBM no tiene nada que ve en esta decisión.
Eso lo piensas tú sin ninguna argumentación.
Yo he expuesto un motivo posible de parar de distribuir Centos "classic" (downstream) y cambiar a Centos upstream. IBM se ha gastado una pasta en la compra de RH el año pasado y quiere forzar a los usuarios de CentOS a pasarse a RHEL. Porque claramente, pocas empresas quieren tener producción en un upstream (en un banco de pruebas hablando claro), sin ningún tipo de estabilidad.
Si tanto sabes dame otro motivo porque no le encuentro otro.
Yo he promovido el binomio CentOS/RH en las empresas en las que he trabajado. Ahora me lo voy a pensar.
#54 pues agradecería que me encontraras algún link de paquetes desaparecidos que no sea que estén en PowerTools, EPEL o que no son parte de RHEL8. PowerTools se mantiene desde CentOS, EPEL desde Fedora y lo que no es parte de RHEL8 se decide en RH. Con lo que CentOS so lo podría liarla en BaseOS, AppStream o PowerTools.
> Ceph no es the RH. Ni siquiera aparece mencionado dentro de los contributors: en.wikipedia.org/wiki/Ceph_(software)
RH compró Inktank, que era la principal empresa tras Ceph y fundada por su creador Sage Weil, en 2014. Ceph no es de la comunidad, pero la compañía con mayor peso tras Ceph es Red Hat y tiene dos productos basados en Ceph: Red Hat Ceph https://www.redhat.com/en/technologies/storage/ceph y OpenShift Container Storage 4 https://www.openshift.com/blog/openshift-container-storage-4-introduction-to-ceph
Puedes ver también el peso de Red Hat en los commits (+60%): https://www.stackalytics.com/unaffiliated?project_type=ceph-group (Sage a veces hacía commits con su viejo mail de DreamHost)
> Eso lo piensas tú sin ninguna argumentación.
Va más allá de un pensamiento, pero no puedo publicar material bajo NDA.
> Si tanto sabes dame otro motivo porque no le encuentro otro.
Hay muchos motivos, pero por NDA tampoco puedo publicarlos.
A mi me duele que no se haya comunicado mejor o incluso que los nombres son liosos. Llamaría a CentOS Stream $otracosa y dejaría CentOS para que lo maneje la comunidad si la hubiera y pudiera hacer adelante con los gastos y demás.
La parte buena es que se ha avisado con suficiente antelación para que se pueda organizar una alternativa. Habrá que ver como se cocina esta, quien lo lleva y cuanta gente se mueve.
#55 no sé de ceph pero parece un caso similar a ansible... espero que no se corrumpa el projecto desde rh.
Bien, entiendo que tengas un nda y que puedan existir otras razones, pero no son para nada aparentes. No parece tener lógica y está siendo muy mal recibido por empresas y comunidad.
Dónde se ha anunciado "con suficiente antelación"? La primera noticia no tiene ni una semana.
La última vez que miré CentOS 8 iba a durar unos buenos años y de repente anuncian un EOL para un año ! Esto ha sentado como una patada. Nada serio.
Impactante foto de la pierna de George Hincapie tras una etapa del tour
cyclingnews.comFoto de la pierna de George Hincapie, ciclista que ha corrido 15 veces el Tour de Francia.
La necesaria derogación del 'decreto Boyer' de alquileres
elpais.comArtículo de 1991 de Isabel Vilallonga. "Tras seis años de vigencia del decreto Boyer, la autora reclama su derogación porque, a su juicio, ha favorecido la especulación urbanística y fomentado la expulsión de 250.000 vecinos de las zonas centrales de la ciudad hacia la periferia."
GNU publica Mediagoblin, proyecto para compatir fotos de manera descentralizada
networkworld.comEl proyecto GNU ha creado Mediagoblin, un sistema para compartir fotos al estilo de Flickr o Picasa pero sin contar con un repositorio centralizado. El código se encuentra disponible en Gitorius y se publica bajo licencia AGPL3.
Timeline de la evolución de HTML
broadcast.rackspace.comTimeline que muestra los cambios que ha habido en el lenguaje HTML y las webs desde que en 1991 se publicara HTML 1.0
Dos viajes he hecho en NEC y la experiencia fue muy buena, salvando quizá el kaos de Penn Station.
Train 172: NEW YORK (PENN STATION), NY - BOSTON (SOUTH STATION), MADepart 11:00 AM, Tuesday, April 30, 2019
2 RESERVED COACH SEATS
$150.00 (los 2 tickets)
TRAIN 2167: BOSTON (SOUTH STATION), MA - NEW YORK (PENN STATION), NYDepart 1:05 PM, Thursday, February 20, 2020
1 ACELA BUSINESS CLASS SEAT
$129.00 (un ticket)
El trayecto eran poco menos de 4 horas en asientos muy cómodos en las 2 clases. El wifi del tren muy malo y la cobertura del móvil mejorable.
Algunos de los compañeros de trabajo con los que hablé se sorprendían que hubiera elegido el tren como opción entre las 2 ciudades, es como si no contemplaran la opción. No viven cerca de la estación y que los accesos al aeropuerto son mejores si han de moverse en coche. En mi caso me hospedaba en hoteles céntricos, con lo que las estaciones de tren me quedaban muy a mano.
En avión el mismo trayecto tiene sobre la hora de duración, pero solo por evitar las colas del aeropuerto sale rentable. En coche y bus eran sobre las 4 horas, siendo el autobús bastante más barato comparado con el tren.