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.
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 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.
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.
#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.
#66 lo que entiendo que dice Nekane sobre el minuto 11:50:
En esta negociación colectiva los sindicatos, como en cualquier empresa, pactan una subida salarial y la empresa dice "no". Va a la baja (la patronal) y plantea: "bueno, un porcentaje lo puedo hacer a través de invertíroslo, osea de dejarlo en lo que va a ser en un fondo de pensiones". Osea, lo que ha sucedido, y yo estuve presente como trabajadora publica vasca y entonces delegada sindical en las negociaciones con las EPSV del sector público vasco, es como se nos ninguneó la subida salarial de un año para invertirlo en el fondo de pensiones con lo cual la aportación que hace la empresa en su momento original es una subida salarial que no realiza y claro esa subida se acumulativa: ya la has perdido ese año y todos los siguientes y ese es el porcentaje que va realizando siempre la empresa. Osea, que si hacemos números puros, que todo integro ha venido de la masa salarial del propio trabajador que ya percibía y que se le negó una subida para dar esto.
> ¿Es cierto esto?
Yo no estuve allí y no he encontrado información de la época que ponga esto en contexto. Si tienes algún artículo lo agradecería. Entiendo que hubo un tira y afloja y que los sindicatos que tenían una idea cedieron a la propuesta de la patronal para que se creara Geroa en vez de la subida salarial.
Su comentario sobre el minuto 13 de que la pensión media son 185€ es interesante. Entiendo que es el caso de los que tienen +45120€ y familiares de fallecidos, ya que el resto puede retirarlo en forma de capital, con lo que la cifra puede estar un poco desvirtuada.
El minuto 14, sobre mileuristas que no llegan a final de mes y piden préstamos por culpa del porcentaje que se va a Geroa creo que necesita más datos que lo acompañen. No digo que no sea posible, que el mundo está jodido, pero es un comentario demasiado abierto.
Del video me quedo con quizá la que sea su parte más clara: "esto quita capacidad de auto gestión de la nómina al propio empleado". Y de ahí entiendo que es su máxima de que si el dinero lo gestiona el Estado para las pensiones públicas está bien, pero si lo gestiona una entidad que no sea pública no. Y esto da para mucho debate.
#54 si hubieran cobrado en negro, no hubieran tenido el 50% que aporta la empresa, pero también se habría ahorrado el IRPF... pero no creo que queramos ir por ahí.
Para mi el problema está en lo que dices, que han creado una desigualdad, que no es lo mismo que corralito. Creo que lo que están intentando hacer es buscar el titular, llámalo clickbait si quieres, para intentar forzar la negociación o un acuerdo más adecuado a sus intereses.
#43 es lo que me hace gracia cuando dicen que han aportado +45120€, cuando una parte grande es de la empresa y otra grande de los intereses creados.
Creo que la plataforma confunde su caso e interés personal faltando a todo el proyecto. ¿qué no pueden sacar todo de golpe? correcto. ¿es un corralito? no.
La de empresas de Gipuzkoa que se benefician de la inversión de Geroa para que sus hijos/nietos puedan tener la calidad de vida que ellos han tenido, pero les prima el interés personal. Entiendo que lo que están intentando es forzar para ver si sacan algo, pero mientras solo están generando ruido y mala fama donde toca.
La "movida" está en que si durante tu vida laboral la aportación del trabajador a Geroa + la aportación de la(s) empresa(s) a Geroa (misma cantidad que el trabajador, es un 1:1) + el retorno de la inversión supera 45120€, no puedes cobrar de una sola vez mientras que si la cantidad es inferior a 45120€ si puedes cobrar todo de golpe. Lo explican en su web:
www.geroa.eus/Geroa-Pentsioak/es/Prestaciones/
- Si tu importe es inferior a 11.280 €, cobrarás en forma de CAPITAL.
- Si tu importe es inferior a 45.120 €, tendrás la opción de cobrar en forma de RENTA o CAPITAL.
- Si tu importe es superior a 45.120 €, cobrarás en forma de RENTA, que puede ser temporal o vitalicia en función de tu edad y del importe exacto, por tal y como se detalla en los Estatutos de la Entidad.
Esto afecta al sector del metal en Gipuzkoa y a otros convenios que se han adherido. En mi caso solo he estado un año en una empresa/convenio que funcionaba con Geroa y por tanto tengo muy poco dinero pero la inversión está así:
- Rentabilidad Geroa 42 %
- Aportado por la empresa 29 %
- Aportado por el empleado 29 %
Para mi Geroa es algo que aporta mucho a Gipuzkoa, mucha capacidad de inversión tanto dentro como fuera que al final beneficia a todos los trabajadores adheridos y por tanto a la sociedad. Ahora, que no sea del agrado de todos... pues eso es otro tema, pero de ahí a "euskocorralito" o "estafa" creo que hay un cacho.
No es una EPSV, no es un fondo de pensiones normal. Es algo específico de Gipuzkoa que se decidió entre la patronal, sindicatos y gobierno.
#1 Estudié en modelo D, que significa usar Euskera como lengua vehicular. Entiendo que también te parecerá una lengua rural o quizá peor. No tengo problema alguno en comunicarme en castellano, he podido disfrutar de esa mejor literatura que dices además de otras. ¿Dónde está el problema?
La "movida" está en que si durante tu vida laboral la aportación del trabajador a Geroa + la aportación de la(s) empresa(s) a Geroa (misma cantidad que el trabajar, es un 1:1) + el retorno de la inversión supera 45120€, no puedes cobrar de una sola vez mientras que si la cantidad es inferior a 45120€ si puedes cobrar todo de golpe. Lo explican en su web:
- Si tu importe es inferior a 11.280 €, cobrarás en forma de CAPITAL.
- Si tu importe es inferior a 45.120 €, tendrás la opción de cobrar en forma de RENTA o CAPITAL.
- Si tu importe es superior a 45.120 €, cobrarás en forma de RENTA, que puede ser temporal o vitalicia en función de tu edad y del importe exacto, por tal y como se detalla en los Estatutos de la Entidad.
Esto afecta al sector del metal en Gipuzkoa y a otros convenios que se han adherido. En mi caso solo he estado un año en una empresa/convenio que funcionaba con Geroa y por tanto tengo muy poco dinero pero la inversión está así:
- Rentabilidad Geroa 42 %
- Aportado por la empresa 29 %
- Aportado por el empleado 29 %
Para mi Geroa es algo que aporta mucho a Gipuzkoa, mucha capacidad de inversión tanto dentro como fuera que al final beneficia a todos los trabajadores adheridos y por tanto a la sociedad. Ahora, que no sea del agrado de todos... pues eso es otro tema, pero de ahí a "euskocorralito" o "estafa" creo que hay un cacho.
Los últimos días me han llegado por redes sociales / grupos varios documentos parecidos a ese y pensaba que este también sería fake. Además, todos los links del artículo son internos. Pero no, la web de ib-salut publica el PDF:
Años de trabajo de la comunidad, Red Hat, Endless, Igalia y otros para que ahora los méritos de todo se los lleve Canonical? ¡Venga ya!
Hoy por hoy la empresa que más invierte en desktop y el resto de tecnologías es Red Hat vía Fedora. El que quiera innovación y estar a la última, le recomiendo Fedora antes que Ubuntu.
#23 que sea libre no significa que no pueda hacer un call-home y enviar datos y métricas. Luego existen aplicaciones como "Debian Popularity Contest" que manda información anónima sobre los paquetes que tienes instalados:
Sobre como calculan los usuarios que tienen, al final de la infografía te dicen de donde salen los datos. El número de gobiernos que trabajan con LibreOffice, colaboradores y número de ficheros soportados es algo que pueden cuantificar fácilmente. El tema de los 100 millones de usuarios viene de lo que ellos saben seguro (contratos con gobiernos y empresas) más una estimación de usuarios que usan Linux.
#32 Equalogic y Compelent son basura comparado con el portfolio de EMC. Dell por ejemplo directamente no tiene nada para competir contra el VMAX de EMC, que es el "rey de la corona" a nivel enterprise.
#11 La Y vasca, tal y como lo han vendido, no tiene sentido.
La Y servirá para conectar con Madrid algún día y con Francia dentro de muuuchos años, pero para conectar las capitales vascas, la infraestructura de carretera actual es más eficiente y barata. Se conectan poco más que las capitales y algunos pueblos que tienen la suerte de que las vías les caen cerca, pero trayectos como Zarautz – Eibar en tren seguirán necesitando 60 minutos y 80 para Zarautz – Durango.
La Y, de vasca, tiene poco; de europea, quizá, algún día.
> 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.