[opensuse-es] Actualizacion: sobre una nueva openSLES o openSuSE LTS
Bueno, Parece que alguna que otra persona del mundo openSuSE empieza a poner criterio en esto: http://lists.opensuse.org/opensuse-project/2009-08/msg00704.html Por cierto: para el que no lo sepa. Dag Wieers es un "hacha" que proviene del mundo Rhel/CentOS. Si lo involucran habrá una openSLES o una openSuSE LTS según decidan ... Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-25 a las 17:16 +0200, carlopmart escribió:
Bueno,
Parece que alguna que otra persona del mundo openSuSE empieza a poner criterio en esto:
http://lists.opensuse.org/opensuse-project/2009-08/msg00704.html
Sí, es curioso. Todo este follón y retahíla de mensajes que ha generado la propuesta de poner a kde como entorno predeterminado, parece que ha llamado la atención de Jason Perlow, editor/gurú/blogero tecnológico y de cierto renombre, que se ha suscrito a la lista de "project" y está haciendo preguntas muy interesantes... Je, si es que "desde fuera" las cosas se ven de otro color y al final terminan por sacarnos los colores >:-)
Por cierto: para el que no lo sepa. Dag Wieers es un "hacha" que proviene del mundo Rhel/CentOS. Si lo involucran habrá una openSLES o una openSuSE LTS según decidan ...
Yo, de verdad, espero que esa idea termine en buen puerto y que se vaya materializando en un programa práctico y realista que se convierta en una alternativa real a la atadura de los "18 meses". Pero creo (IMO) que, desgraciadamente, no va a llegar a ningún lado... :-( Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-25 a las 17:16 +0200, carlopmart escribió:
Bueno,
Parece que alguna que otra persona del mundo openSuSE empieza a poner criterio en esto:
http://lists.opensuse.org/opensuse-project/2009-08/msg00704.html
Sí, es curioso.
Todo este follón y retahíla de mensajes que ha generado la propuesta de poner a kde como entorno predeterminado, parece que ha llamado la atención de Jason Perlow, editor/gurú/blogero tecnológico y de cierto renombre, que se ha suscrito a la lista de "project" y está haciendo preguntas muy interesantes...
Je, si es que "desde fuera" las cosas se ven de otro color y al final terminan por sacarnos los colores >:-)
Por cierto: para el que no lo sepa. Dag Wieers es un "hacha" que proviene del mundo Rhel/CentOS. Si lo involucran habrá una openSLES o una openSuSE LTS según decidan ...
Yo, de verdad, espero que esa idea termine en buen puerto y que se vaya materializando en un programa práctico y realista que se convierta en una alternativa real a la atadura de los "18 meses".
Pero creo (IMO) que, desgraciadamente, no va a llegar a ningún lado... :-(
Saludos,
Bueno la esperanza es lo último que se pierde :)). Fuera bromas, lo digo en serio: si convencen a Dag Wieers, dá por hecho que habrá una distro. El problema más importante que veo con Dag es que es una persona que se centra en temas de linea Enterprise, por eso veo dificil que le convenzan para un openSuSE LTS (aunque todo es posible). Si le dicen que será una openSLES es muy probable que se apunte al carro, ya que en estos momentos ha dejado de ser desarrollador/colaborador de CentOS. Otro apunte: es uno de los responsables de rpmforge, por lo tanto tiene infraestructura como para crear una distro desde cero. Pero solo el tiempo dirá ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-25 a las 19:53 +0200, carlopmart escribió:
Camaleón wrote:
Por cierto: para el que no lo sepa. Dag Wieers es un "hacha" que proviene del mundo Rhel/CentOS. Si lo involucran habrá una openSLES o una openSuSE LTS según decidan ...
Yo, de verdad, espero que esa idea termine en buen puerto y que se vaya materializando en un programa práctico y realista que se convierta en una alternativa real a la atadura de los "18 meses". Pero creo (IMO) que, desgraciadamente, no va a llegar a ningún lado... :-(
Bueno la esperanza es lo último que se pierde :)). Fuera bromas, lo digo en serio: si convencen a Dag Wieers, dá por hecho que habrá una distro. El problema más importante que veo con Dag es que es una persona que se centra en temas de linea Enterprise, por eso veo dificil que le convenzan para un openSuSE LTS (aunque todo es posible). Si le dicen que será una openSLES es muy probable que se apunte al carro, ya que en estos momentos ha dejado de ser desarrollador/colaborador de CentOS. Otro apunte: es uno de los responsables de rpmforge, por lo tanto tiene infraestructura como para crear una distro desde cero. Pero solo el tiempo dirá ...
No es tarea fácil... no sólo por la cantidad de paquetes que tendrían que mantener, empaquetar, probar y compatibilizar, sino porque tendría a Novell encima... No sé, no lo veo tarea para una sola persona sino maś bien para un grupo dedicado íntegramente a ese trabajo. Y por las listas y foros no veo que la gente (que no es de Novell) esté por esa labor. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-25 a las 19:53 +0200, carlopmart escribió:
Camaleón wrote:
Por cierto: para el que no lo sepa. Dag Wieers es un "hacha" que proviene del mundo Rhel/CentOS. Si lo involucran habrá una openSLES o una openSuSE LTS según decidan ...
Yo, de verdad, espero que esa idea termine en buen puerto y que se vaya materializando en un programa práctico y realista que se convierta en una alternativa real a la atadura de los "18 meses". Pero creo (IMO) que, desgraciadamente, no va a llegar a ningún lado... :-( Bueno la esperanza es lo último que se pierde :)). Fuera bromas, lo digo en serio: si convencen a Dag Wieers, dá por hecho que habrá una distro. El problema más importante que veo con Dag es que es una persona que se centra en temas de linea Enterprise, por eso veo dificil que le convenzan para un openSuSE LTS (aunque todo es posible). Si le dicen que será una openSLES es muy probable que se apunte al carro, ya que en estos momentos ha dejado de ser desarrollador/colaborador de CentOS. Otro apunte: es uno de los responsables de rpmforge, por lo tanto tiene infraestructura como para crear una distro desde cero. Pero solo el tiempo dirá ...
No es tarea fácil... no sólo por la cantidad de paquetes que tendrían que mantener, empaquetar, probar y compatibilizar, sino porque tendría a Novell encima... No sé, no lo veo tarea para una sola persona sino maś bien para un grupo dedicado íntegramente a ese trabajo. Y por las listas y foros no veo que la gente (que no es de Novell) esté por esa labor.
Saludos,
Cierto no es una tarea fácil, pero me remito a un correo anterior que comenté: CentOS solo dispone de 8 desarrolladores y ScientificLinux de 2 y las distros salen, aunque bien es cierto que con CentOS 5.3 hubo algunos problemas pero bueno. De todas formas lo que yo si veo muy dificl de mantener es una openSuSE LTS: son demasiados paquetes y ahí si que tendría que haber unas cuantas personas. Por contra, una openSLES sería "más fácil" de mantener y que aporta muchísimos menos paquetes que openSuSE, pero el handicap con openSLES está en cumplir la ley, aunque en teoría el código de SLES es gratuito, ¿o no Novell?? saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-25 a las 23:24 +0200, carlopmart escribió:
Camaleón wrote:
Bueno la esperanza es lo último que se pierde :)). Fuera bromas, lo digo en serio: si convencen a Dag Wieers, dá por hecho que habrá una distro. El problema más importante que veo con Dag es que es una persona que se centra en temas de linea Enterprise, por eso veo dificil que le convenzan para un openSuSE LTS (aunque todo es posible). Si le dicen que será una openSLES es muy probable que se apunte al carro, ya que en estos momentos ha dejado de ser desarrollador/colaborador de CentOS. Otro apunte: es uno de los responsables de rpmforge, por lo tanto tiene infraestructura como para crear una distro desde cero. Pero solo el tiempo dirá ...
No es tarea fácil... no sólo por la cantidad de paquetes que tendrían que mantener, empaquetar, probar y compatibilizar, sino porque tendría a Novell encima... No sé, no lo veo tarea para una sola persona sino maś bien para un grupo dedicado íntegramente a ese trabajo. Y por las listas y foros no veo que la gente (que no es de Novell) esté por esa labor. Saludos,
Cierto no es una tarea fácil, pero me remito a un correo anterior que comenté: CentOS solo dispone de 8 desarrolladores y ScientificLinux de 2 y las distros salen, aunque bien es cierto que con CentOS 5.3 hubo algunos problemas pero bueno.
Pero en CentOS utilizan los mismos paquetes que en RedHat, sólo les quitan aquéllo que no pueden distribuir por problemas de licencias. Es decir, no desarrollan paquetes nuevos, sólo manipulan los existentes. Los parches, las mejoras, se las "da" (por decirlo de alguna manera) RedHat, ya hechas.
De todas formas lo que yo si veo muy dificl de mantener es una openSuSE LTS: son demasiados paquetes y ahí si que tendría que haber unas cuantas personas. Por contra, una openSLES sería "más fácil" de mantener y que aporta muchísimos menos paquetes que openSuSE, pero el handicap con openSLES está en cumplir la ley, aunque en teoría el código de SLES es gratuito, ¿o no Novell??
Una openSUSE LTS requiere de personal encargado de testeo... y mucho. Porque no tienen paquetes, tiene que parchear el kernel, y mantener estables y compatibles todos los paquetes que saquen alguna actualización de seguridad y eso no lo veo sencillo. Novell pondría menos pegas (por no decir ninguna porque no puede) pero faltaría "mano de obra". A una openSLES Novell la pondría contra la espada y la pared. Técnicamente sería más sencillo de mantener (los paquetes serían los mismos que los de SLES/SLES por lo que del testeo ya se encargarían ellos :-P) pero legalmente sería más complicado. No sé cómo consiguen los últimos parches de seguridad de RedHat la gente de CentOS pero en SLES me parece que necesitas al menos tener una cuenta para descargar no sólo los paquetes sino para tener acceso su código fuente. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-25 a las 23:24 +0200, carlopmart escribió:
Camaleón wrote:
Bueno la esperanza es lo último que se pierde :)). Fuera bromas, lo digo en serio: si convencen a Dag Wieers, dá por hecho que habrá una distro. El problema más importante que veo con Dag es que es una persona que se centra en temas de linea Enterprise, por eso veo dificil que le convenzan para un openSuSE LTS (aunque todo es posible). Si le dicen que será una openSLES es muy probable que se apunte al carro, ya que en estos momentos ha dejado de ser desarrollador/colaborador de CentOS. Otro apunte: es uno de los responsables de rpmforge, por lo tanto tiene infraestructura como para crear una distro desde cero. Pero solo el tiempo dirá ...
No es tarea fácil... no sólo por la cantidad de paquetes que tendrían que mantener, empaquetar, probar y compatibilizar, sino porque tendría a Novell encima... No sé, no lo veo tarea para una sola persona sino maś bien para un grupo dedicado íntegramente a ese trabajo. Y por las listas y foros no veo que la gente (que no es de Novell) esté por esa labor. Saludos,
Cierto no es una tarea fácil, pero me remito a un correo anterior que comenté: CentOS solo dispone de 8 desarrolladores y ScientificLinux de 2 y las distros salen, aunque bien es cierto que con CentOS 5.3 hubo algunos problemas pero bueno.
Pero en CentOS utilizan los mismos paquetes que en RedHat, sólo les quitan aquéllo que no pueden distribuir por problemas de licencias. Es decir, no desarrollan paquetes nuevos, sólo manipulan los existentes.
Los parches, las mejoras, se las "da" (por decirlo de alguna manera) RedHat, ya hechas.
Exacto. Es lo mismo que se haria con openSLES. Nadie dice que openSLES deba asumir nada más.
De todas formas lo que yo si veo muy dificl de mantener es una openSuSE LTS: son demasiados paquetes y ahí si que tendría que haber unas cuantas personas. Por contra, una openSLES sería "más fácil" de mantener y que aporta muchísimos menos paquetes que openSuSE, pero el handicap con openSLES está en cumplir la ley, aunque en teoría el código de SLES es gratuito, ¿o no Novell??
Una openSUSE LTS requiere de personal encargado de testeo... y mucho.
Eso y mucha gente compilando paquetes, que no son pocos ...
Porque no tienen paquetes, tiene que parchear el kernel, y mantener estables y compatibles todos los paquetes que saquen alguna actualización de seguridad y eso no lo veo sencillo. Novell pondría menos pegas (por no decir ninguna porque no puede) pero faltaría "mano de obra".
A una openSLES Novell la pondría contra la espada y la pared.
¿Porque? Red Hat no lo está existiendo una CentOS o ScientificLinux como existen.
Técnicamente sería más sencillo de mantener (los paquetes serían los mismos que los de SLES/SLES por lo que del testeo ya se encargarían ellos :-P) pero legalmente sería más complicado.
Ahí está el quid: saber si Novell ha metido algún gazapo por el cual no se pueda hacer una openSLES. No sé cómo consiguen
los últimos parches de seguridad de RedHat la gente de CentOS pero en SLES me parece que necesitas al menos tener una cuenta para descargar no sólo los paquetes sino para tener acceso su código fuente.
Pues con Red Hat es muy facil. Coges un navegador y entras aquí: http://ftp.redhat.com/pub/redhat/linux/enterprise/. Ala, ya tienes todo el código fuente de todas las releases de Red Hat Enterprise más los updates que tocan. Ni usuario, ni password ni nada: un simple ftp. Si esta gente va en serio y legalmente no hay ningún problema en crear una openSLES, la primera donación está clara: dinero para tener una subscripción para todos los canales posibles de SLES. Esto no es nuevo, las personas de CentOS también tienen cuentas legales en Red Hat con acceso completo a todo. Por lo tanto si desde un punto de vista legal no hay problema, no es complicado liberar un openSLES ya que la financiación no debería costarles en exceso encontrarla, eso si SuSE tiene una buena base de usuarios, sean empresariales o no. Saludos.
Saludos,
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 00:03 +0200, carlopmart escribió:
Camaleón wrote:
Una openSUSE LTS requiere de personal encargado de testeo... y mucho.
Eso y mucha gente compilando paquetes, que no son pocos ...
Porque no tienen paquetes, tiene que parchear el kernel, y mantener estables y compatibles todos los paquetes que saquen alguna actualización de seguridad y eso no lo veo sencillo. Novell pondría menos pegas (por no decir ninguna porque no puede) pero faltaría "mano de obra". A una openSLES Novell la pondría contra la espada y la pared.
¿Porque? Red Hat no lo está existiendo una CentOS o ScientificLinux como existen.
Digamos que, en ese aspecto, yo diría que Novell no es como Red Hat :-)
Técnicamente sería más sencillo de mantener (los paquetes serían los mismos que los de SLES/SLES por lo que del testeo ya se encargarían ellos :-P) pero legalmente sería más complicado.
Ahí está el quid: saber si Novell ha metido algún gazapo por el cual no se pueda hacer una openSLES.
No sé cómo consiguen
los últimos parches de seguridad de RedHat la gente de CentOS pero en SLES me parece que necesitas al menos tener una cuenta para descargar no sólo los paquetes sino para tener acceso su código fuente.
Pues con Red Hat es muy facil. Coges un navegador y entras aquí: http://ftp.redhat.com/pub/redhat/linux/enterprise/. Ala, ya tienes todo el código fuente de todas las releases de Red Hat Enterprise más los updates que tocan. Ni usuario, ni password ni nada: un simple ftp.
Si esta gente va en serio y legalmente no hay ningún problema en crear una openSLES, la primera donación está clara: dinero para tener una subscripción para todos los canales posibles de SLES. Esto no es nuevo, las personas de CentOS también tienen cuentas legales en Red Hat con acceso completo a todo.
Por lo tanto si desde un punto de vista legal no hay problema, no es complicado liberar un openSLES ya que la financiación no debería costarles en exceso encontrarla, eso si SuSE tiene una buena base de usuarios, sean empresariales o no.
Aquí tienes algunas respuestas: Why is there no Open Source SLES? http://dag.wieers.com/blog/why-is-there-no-open-source-sles Y fíjate en quién es el autor del blog ;-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 00:03 +0200, carlopmart escribió:
Camaleón wrote:
Una openSUSE LTS requiere de personal encargado de testeo... y mucho. Eso y mucha gente compilando paquetes, que no son pocos ...
Porque no tienen paquetes, tiene que parchear el kernel, y mantener estables y compatibles todos los paquetes que saquen alguna actualización de seguridad y eso no lo veo sencillo. Novell pondría menos pegas (por no decir ninguna porque no puede) pero faltaría "mano de obra". A una openSLES Novell la pondría contra la espada y la pared. ¿Porque? Red Hat no lo está existiendo una CentOS o ScientificLinux como existen.
Digamos que, en ese aspecto, yo diría que Novell no es como Red Hat :-)
Técnicamente sería más sencillo de mantener (los paquetes serían los mismos que los de SLES/SLES por lo que del testeo ya se encargarían ellos :-P) pero legalmente sería más complicado. Ahí está el quid: saber si Novell ha metido algún gazapo por el cual no se pueda hacer una openSLES.
No sé cómo consiguen
los últimos parches de seguridad de RedHat la gente de CentOS pero en SLES me parece que necesitas al menos tener una cuenta para descargar no sólo los paquetes sino para tener acceso su código fuente. Pues con Red Hat es muy facil. Coges un navegador y entras aquí: http://ftp.redhat.com/pub/redhat/linux/enterprise/. Ala, ya tienes todo el código fuente de todas las releases de Red Hat Enterprise más los updates que tocan. Ni usuario, ni password ni nada: un simple ftp.
Si esta gente va en serio y legalmente no hay ningún problema en crear una openSLES, la primera donación está clara: dinero para tener una subscripción para todos los canales posibles de SLES. Esto no es nuevo, las personas de CentOS también tienen cuentas legales en Red Hat con acceso completo a todo.
Por lo tanto si desde un punto de vista legal no hay problema, no es complicado liberar un openSLES ya que la financiación no debería costarles en exceso encontrarla, eso si SuSE tiene una buena base de usuarios, sean empresariales o no.
Aquí tienes algunas respuestas:
Why is there no Open Source SLES? http://dag.wieers.com/blog/why-is-there-no-open-source-sles
Y fíjate en quién es el autor del blog ;-)
Saludos,
Concozco la entrada, de hecho la provocamos en la lista de CentOS varias personas. Yo estoy de acuerdo con Dag en lo que dice ahí, pero también es cierto que lo que comentan Jason Perlow y Boyd Lynn Gerber en la lista recién creada podría ser factible. De todas formas, si no se involucra alguien de mucho peso de la comunidad SuSE (así es como nació CentOS, con gente muy relevante de la comunidad Fedora y partners de Red Hat) y que no tenga nada que ver con Novell, es cierto que esto no se hará. De nada serviría por ejemplo que nos apuntásemos todas las personas de esta lista. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 08:58 +0200, carlopmart escribió:
Camaleón wrote:
Si esta gente va en serio y legalmente no hay ningún problema en crear una openSLES, la primera donación está clara: dinero para tener una subscripción para todos los canales posibles de SLES. Esto no es nuevo, las personas de CentOS también tienen cuentas legales en Red Hat con acceso completo a todo.
Por lo tanto si desde un punto de vista legal no hay problema, no es complicado liberar un openSLES ya que la financiación no debería costarles en exceso encontrarla, eso si SuSE tiene una buena base de usuarios, sean empresariales o no.
Aquí tienes algunas respuestas:
Why is there no Open Source SLES? http://dag.wieers.com/blog/why-is-there-no-open-source-sles
Y fíjate en quién es el autor del blog ;-)
Concozco la entrada, de hecho la provocamos en la lista de CentOS varias personas. Yo estoy de acuerdo con Dag en lo que dice ahí, pero también es cierto que lo que comentan Jason Perlow y Boyd Lynn Gerber en la lista recién creada podría ser factible. De todas formas, si no se involucra alguien de mucho peso de la comunidad SuSE (así es como nació CentOS, con gente muy relevante de la comunidad Fedora y partners de Red Hat) y que no tenga nada que ver con Novell, es cierto que esto no se hará. De nada serviría por ejemplo que nos apuntásemos todas las personas de esta lista.
El problema es que, según los comentarios que hacen en ese blog, parece que los parches de seguridad de SLES no están disponibles para su descarga pública en el momento en que se publican, al contrario de lo que sucede en Red Hat. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 08:58 +0200, carlopmart escribió:
Camaleón wrote:
Si esta gente va en serio y legalmente no hay ningún problema en crear una openSLES, la primera donación está clara: dinero para tener una subscripción para todos los canales posibles de SLES. Esto no es nuevo, las personas de CentOS también tienen cuentas legales en Red Hat con acceso completo a todo.
Por lo tanto si desde un punto de vista legal no hay problema, no es complicado liberar un openSLES ya que la financiación no debería costarles en exceso encontrarla, eso si SuSE tiene una buena base de usuarios, sean empresariales o no.
Aquí tienes algunas respuestas:
Why is there no Open Source SLES? http://dag.wieers.com/blog/why-is-there-no-open-source-sles
Y fíjate en quién es el autor del blog ;-)
Concozco la entrada, de hecho la provocamos en la lista de CentOS varias personas. Yo estoy de acuerdo con Dag en lo que dice ahí, pero también es cierto que lo que comentan Jason Perlow y Boyd Lynn Gerber en la lista recién creada podría ser factible. De todas formas, si no se involucra alguien de mucho peso de la comunidad SuSE (así es como nació CentOS, con gente muy relevante de la comunidad Fedora y partners de Red Hat) y que no tenga nada que ver con Novell, es cierto que esto no se hará. De nada serviría por ejemplo que nos apuntásemos todas las personas de esta lista.
El problema es que, según los comentarios que hacen en ese blog, parece que los parches de seguridad de SLES no están disponibles para su descarga pública en el momento en que se publican, al contrario de lo que sucede en Red Hat.
Saludos,
Eso es salvable si el equipo de desarrollo tiene dinero para contratar subscripciones en Novell. Pero hay un problema muy importante: la licencia de YaST. Hasta donde yo sé, no es GPL y teniendo en cuenta que yast está integradísimo en SLES, es un problema importante (aunque por mi parte yo no uso YaST o sea que como si no quieren ni incluirla). Por eso si buscais por google podréis ver gente que opina que se podría hacer un "CentOS Green", esto es una free SLES pero con el instalador anaconda, pero esa opción me parece que todavía tiene menos futuro que las expuestas ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 09:28 +0200, carlopmart escribió:
Camaleón wrote:
Aquí tienes algunas respuestas:
Why is there no Open Source SLES? http://dag.wieers.com/blog/why-is-there-no-open-source-sles
Y fíjate en quién es el autor del blog ;-)
Concozco la entrada, de hecho la provocamos en la lista de CentOS varias personas. Yo estoy de acuerdo con Dag en lo que dice ahí, pero también es cierto que lo que comentan Jason Perlow y Boyd Lynn Gerber en la lista recién creada podría ser factible. De todas formas, si no se involucra alguien de mucho peso de la comunidad SuSE (así es como nació CentOS, con gente muy relevante de la comunidad Fedora y partners de Red Hat) y que no tenga nada que ver con Novell, es cierto que esto no se hará. De nada serviría por ejemplo que nos apuntásemos todas las personas de esta lista.
El problema es que, según los comentarios que hacen en ese blog, parece que los parches de seguridad de SLES no están disponibles para su descarga pública en el momento en que se publican, al contrario de lo que sucede en Red Hat. Saludos,
Eso es salvable si el equipo de desarrollo tiene dinero para contratar subscripciones en Novell.
Habrá que leer el contrato antes para saber cuáles son tus obligaciones y deberes como cliente :-). Que no hagan públicos los parches no me da buena espina.
Pero hay un problema muy importante: la licencia de YaST. Hasta donde yo sé, no es GPL y teniendo en cuenta que yast está integradísimo en SLES, es un problema importante (aunque por mi parte yo no uso YaST o sea que como si no quieren ni incluirla).
Eso no lo veo un problema porque YaST es GPL desde algún tiempo (si no recuerdo mal) y aún así, si fuera cerrado, tienes instaladores para aburrir.
Por eso si buscais por google podréis ver gente que opina que se podría hacer un "CentOS Green", esto es una free SLES pero con el instalador anaconda, pero esa opción me parece que todavía tiene menos futuro que las expuestas ...
Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
carlopmart escribió:
Camaleón wrote:
El 2009-08-26 a las 08:58 +0200, carlopmart escribió:
Eso es salvable si el equipo de desarrollo tiene dinero para contratar subscripciones en Novell. Pero hay un problema muy importante: la licencia de YaST. Hasta donde yo sé, no es GPL y teniendo en cuenta que yast está integradísimo en SLES, es un problema importante (aunque por mi parte yo no uso YaST o sea que como si no quieren ni incluirla).
Quizás, si usaras YaST, sabrías buscar en él:
yast2 - YaST2 - Main Package
Versión alternativa
Versión instalada
Versión:
2.16.71-6.1
2.16.71-6.1
Hora de construcción:
sáb 07 jun 2008 06:15:59 CEST
sáb 07 jun 2008 06:15:59 CEST
Hora de instalación:
mar 10 jun 2008 14:24:45 CEST
Grupo de paquetes:
System/YaST
System/YaST
Licencia:
GPL v2 or later
GPL v2 or later
Tamaño instalado:
3.1 M
3.1 M
Tamaño de la descarga:
588.0 K
0 B
Distribución:
Fabricante:
SUSE LINUX Products GmbH, Nuernberg, Germany
SUSE LINUX Products GmbH, Nuernberg, Germany
Empaquetador:
Arquitectura:
x86_64
x86_64
Servidor de construcción:
URL:
Número de medio:
1
0
Autores:
Michael Andres
Por eso si buscais por google podréis ver gente que opina que se podría hacer un "CentOS Green", esto es una free SLES pero con el instalador anaconda, pero esa opción me parece que todavía tiene menos futuro que las expuestas ...
-- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Miércoles, 26 de Agosto de 2009 09:28:05 carlopmart escribió:
Por eso si buscais por google podréis ver gente que opina que se podría hacer un "CentOS Green", esto es una free SLES pero con el instalador anaconda, pero esa opción me parece que todavía tiene menos futuro que las expuestas ...
Desde mi punto de vista, eso sería derrochar un tiempo precioso en fabricar un "monstruo de siete cabezas" que no aportaría nada útil comparado con otras alternativas ya disponibles. Miquel. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Martes, 25 de Agosto de 2009 19:47:57 Camaleón escribió:
Yo, de verdad, espero que esa idea termine en buen puerto y que se vaya materializando en un programa práctico y realista que se convierta en una alternativa real a la atadura de los "18 meses".
Pero creo (IMO) que, desgraciadamente, no va a llegar a ningún lado... :-(
+1 IMHO la única opción lógica y sensata sería: a) Decidir que verisones van a ser LTS (pongamos por caso, las XX.0) b) Definir que subconjunto de paquetes queremos que sean LTS (kernel, apache, openssh, mysql...) c) Crear el repositorio "lts" donde estarían los paquetes del punto b) para todas las versiones "menores" de la serie XX Así los usuarios podríamos actualizar vía 'zypper dup -l' cada vez que nos parezca oportuno pero con la tranquilidad de saber que, en caso de problemas de compatibilidad, siempre vamos a poder mantener los paquetes de la versión base. A los desarrolladores también les vendría bien el sistema ya que no tendrían que mantener una distribución completa, instalador, etc. Saludos. Miquel. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Yo lo veo mucho mas sencillo.
Apuntar a una openSLES, tener una suscripción a novell y de ahi
obtener los parches de seguridad y las actualizaciones criticas, el
resto se obtiene de las iso normales.
También aprovechar el OBS para empaquetar software mas reciente, como
Postgresql, Apache, tomcat, etc. etc.
Luego quedaría eliminar toda referencia a novell y poner la marca openSLES
No hay ningún paquete indispensable en SLES que tenga una licencia
restrictiva que impida que el proyecto no corra.
Saludos!
El 26 de agosto de 2009 06:29, Miquel A. Noguera
El Martes, 25 de Agosto de 2009 19:47:57 Camaleón escribió:
Yo, de verdad, espero que esa idea termine en buen puerto y que se vaya materializando en un programa práctico y realista que se convierta en una alternativa real a la atadura de los "18 meses".
Pero creo (IMO) que, desgraciadamente, no va a llegar a ningún lado... :-(
+1
IMHO la única opción lógica y sensata sería:
a) Decidir que verisones van a ser LTS (pongamos por caso, las XX.0)
b) Definir que subconjunto de paquetes queremos que sean LTS (kernel, apache, openssh, mysql...)
c) Crear el repositorio "lts" donde estarían los paquetes del punto b) para todas las versiones "menores" de la serie XX
Así los usuarios podríamos actualizar vía 'zypper dup -l' cada vez que nos parezca oportuno pero con la tranquilidad de saber que, en caso de problemas de compatibilidad, siempre vamos a poder mantener los paquetes de la versión base.
A los desarrolladores también les vendría bien el sistema ya que no tendrían que mantener una distribución completa, instalador, etc.
Saludos. Miquel. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 07:36 -0400, Armin Díaz Argaña escribió:
Yo lo veo mucho mas sencillo.
Eso debe ser porque aún no has hablado con tu comercial de Novell y le has planteado la idea >:-)
Apuntar a una openSLES, tener una suscripción a novell y de ahi obtener los parches de seguridad y las actualizaciones criticas, el resto se obtiene de las iso normales.
¿Y quién se encarga de "limpiar" los paquetes para que se puedan distribuir e instalar sin violar el EULA de Novell? ¿Y cómo sabemos qué es lo que hay que eliminar? ¿Y quién hace las pruebas de esos paquetes antes de ponerlos a disposición de todos? Porque si algo falla, no se puede recurrir a "naide" :-)
También aprovechar el OBS para empaquetar software mas reciente, como Postgresql, Apache, tomcat, etc. etc.
Luego quedaría eliminar toda referencia a novell y poner la marca openSLES
Sin colaboración por parte de Novell, yo no lo veo tan simple de ejecutar como en CentOS / Red Hat :-/
No hay ningún paquete indispensable en SLES que tenga una licencia restrictiva que impida que el proyecto no corra.
Empaquetar es sencillo (hasta cierto punto) y ¿las pruebas? ¿o no se prueban los paquetes antes y si cascan, bueno, pues "ajo y agua"? >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 07:36 -0400, Armin Díaz Argaña escribió:
Yo lo veo mucho mas sencillo.
Eso debe ser porque aún no has hablado con tu comercial de Novell y le has planteado la idea >:-)
Apuntar a una openSLES, tener una suscripción a novell y de ahi obtener los parches de seguridad y las actualizaciones criticas, el resto se obtiene de las iso normales.
¿Y quién se encarga de "limpiar" los paquetes para que se puedan distribuir e instalar sin violar el EULA de Novell? ¿Y cómo sabemos qué es lo que hay que eliminar? ¿Y quién hace las pruebas de esos paquetes antes de ponerlos a disposición de todos? Porque si algo falla, no se puede recurrir a "naide" :-)
También aprovechar el OBS para empaquetar software mas reciente, como Postgresql, Apache, tomcat, etc. etc.
Luego quedaría eliminar toda referencia a novell y poner la marca openSLES
Sin colaboración por parte de Novell, yo no lo veo tan simple de ejecutar como en CentOS / Red Hat :-/
No hay ningún paquete indispensable en SLES que tenga una licencia restrictiva que impida que el proyecto no corra.
Empaquetar es sencillo (hasta cierto punto) y ¿las pruebas? ¿o no se prueban los paquetes antes y si cascan, bueno, pues "ajo y agua"? >:-)
Saludos,
Camaleon, todas esas dudas que planteas son muy sencillas de resolver. A nivel técnico no hay problemas. Lo que ha planteado Armin es precisamente el modelo que usa CentOS a) "Limpieza" de trademarks y temas relacionados: equipo de desarrolladores (en CentOS son 8 personas nada más). Y sabemos lo que se puede eliminar porque hay acceso al código fuente. b) Realización de las pruebas: el equipo de QA. Aquí cuantas más personas y distintos entornos haya involucrados mejor, pero recordad que la parte más dura ya la ha hecho Novell. Solo hay que asegurarse de que la distro funciona igual a la original, incluyendo los mismos problemas que pueda tener SLES. c) Recurrir cuando algo falla: pues donde siempre a los foros y las mailing lists. ¿Como creeis que se hacia con CentOS en los inicios?. Sigue siendo igual, aunque es cierto que sí existen empresas dando soporte "oficial". d) En el caso de una openSLES, yo no meteria nada de OBS. Se trata de que sea un fiel reflejo de la distro original: quiero decir yo no empaquetaria nada que no estuviese en el DVD oficial. Eso sí, se puede crear un repositorio como extras e incluir el software más demandado por los usuarios, vamos el equivalente a universe y multiverse de Ubuntu. e) Colaboración de Novell: la justita. Quiero decir que si se tiene acceso a la subscripción no se necesita a Novell para nada. La herramienta SMT de SLES ya te descarga todos los fuentes de los updates y los paquetes originales. Para mi el handicap es averiguar si legalmente se puede hacer y lo demás no tiene problemas ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
carlopmart escribió:
Camaleón wrote:
El 2009-08-26 a las 07:36 -0400, Armin Díaz Argaña escribió:
Para mi el handicap es averiguar si legalmente se puede hacer y lo demás no tiene problemas ...
Pues es muy sencillo. Sobre todo lo que está en el repo oss OpenSuSE es GPL, y por tanto puedes hacer con él lo que te de la gana. Bien, Compraras la SLS con OpenSuSE, y los paquetes que no coincidan... compruebas cuáles no son GPL. Los que no lo sean... directamente a la basura... Y ya lo puedes hacer. ¿Que a Novell no le va a gustar? No le va a gustar nada. Se va a coger un cabreo a lo JeZulín de Ubrike... en dos palabras: IM PRSIONANTE... ¿Qué Novell hará lo posible y lo imposible para hacerte la vida imposible? Lo hará, demandas judiciales incluidas, aún a sabiendas de que las va a perder, -pero tú perderás tiempo, y MUCHO dinero, que a ellos les sobra-... Para defenderte tendría que estar el "payaso" Stallman y su FSF... pero no lo hará. Vive muy bien. Para mí es como Teddy Baustista, sólo que en vea de la SGAE, de la FSF. -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
csalinux wrote:
carlopmart escribió:
Camaleón wrote:
El 2009-08-26 a las 07:36 -0400, Armin Díaz Argaña escribió:
Para mi el handicap es averiguar si legalmente se puede hacer y lo demás no tiene problemas ...
Pues es muy sencillo. Sobre todo lo que está en el repo oss OpenSuSE es GPL, y por tanto puedes hacer con él lo que te de la gana.
Bien, Compraras la SLS con OpenSuSE, y los paquetes que no coincidan... compruebas cuáles no son GPL. Los que no lo sean... directamente a la basura... Y ya lo puedes hacer.
¿Que a Novell no le va a gustar?
No le va a gustar nada. Se va a coger un cabreo a lo JeZulín de Ubrike... en dos palabras: IM PRSIONANTE...
¿Qué Novell hará lo posible y lo imposible para hacerte la vida imposible? Lo hará, demandas judiciales incluidas, aún a sabiendas de que las va a perder, -pero tú perderás tiempo, y MUCHO dinero, que a ellos les sobra-... Para defenderte tendría que estar el "payaso" Stallman y su FSF... pero no lo hará. Vive muy bien. Para mí es como Teddy Baustista, sólo que en vea de la SGAE, de la FSF.
Si sé que tienes razón: Novell por lo que veo que todos conocemos pondrá trabas, pero ¿alguien sabe si se le ha tanteado de verdad a Novell este tema?? Y hablo de Novell en Alemania o USA, no en España que esto son un pelín "abrazafarolas" (dicho desde el cariño, claro). Ese punto es importante saberlo. Yo creo que dentro de SuSE/Novell esto habrá acaparado alguna que otra reunión seria .... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 26 August 2009 14:31:55 csalinux wrote:
carlopmart escribió:
Camaleón wrote:
El 2009-08-26 a las 07:36 -0400, Armin Díaz Argaña escribió:
Para mi el handicap es averiguar si legalmente se puede hacer y lo demás no tiene problemas ...
Pues es muy sencillo. Sobre todo lo que está en el repo oss OpenSuSE es GPL, y por tanto puedes hacer con él lo que te de la gana.
Puede que no sea GPL, puede ser LGPL o X11 o BSD o ... Vamos que son licencias que permiten la libre distribución. En todo caso, no puedes hacer lo que te da la gana ya que no puedes (debes) cerrar el código al menos en aquellas que son GPL o LGPL.
Bien, Compraras la SLS con OpenSuSE, y los paquetes que no coincidan... compruebas cuáles no son GPL. Los que no lo sean... directamente a la basura... Y ya lo puedes hacer.
Puedes hacer algo más sencillo que es pillar todos los rpms de SLES y hacer
un:
rpm -qpi *.rpm | grep -i license | grep -B <#_líneas_hasta_nom_paquete>
Creo que era algo así. No tengo un SUSE aquí a mano así que no lo puedo
probar. Lo hice una vez por curiosidad. Te debería dar el nombre del paquete y
su licencia. El que tenga un SUSE por ahí, que lo pruebe.
Hay otra posibilidad. Antes, el SLES tenía un fichero ARCHIVE.gz (si no
recuerdo mal el nombre) en el que venían listados todos los paquetes y su info
(vamos, como si haces un rpm -qpil *). Se podría hacer ahí un grep también:
zgrep -iE "(
El 2009-08-27 a las 08:26 +0200, Rafa Grimán escribió:
On Wednesday 26 August 2009 14:31:55 csalinux wrote:
Para mi el handicap es averiguar si legalmente se puede hacer y lo demás no tiene problemas ...
Pues es muy sencillo. Sobre todo lo que está en el repo oss OpenSuSE es GPL, y por tanto puedes hacer con él lo que te de la gana.
Puede que no sea GPL, puede ser LGPL o X11 o BSD o ... Vamos que son licencias que permiten la libre distribución. En todo caso, no puedes hacer lo que te da la gana ya que no puedes (debes) cerrar el código al menos en aquellas que son GPL o LGPL.
Bien, Compraras la SLS con OpenSuSE, y los paquetes que no coincidan... compruebas cuáles no son GPL. Los que no lo sean... directamente a la basura... Y ya lo puedes hacer.
Puedes hacer algo más sencillo que es pillar todos los rpms de SLES y hacer un:
rpm -qpi *.rpm | grep -i license | grep -B <#_líneas_hasta_nom_paquete>
Creo que era algo así. No tengo un SUSE aquí a mano así que no lo puedo probar. Lo hice una vez por curiosidad. Te debería dar el nombre del paquete y su licencia. El que tenga un SUSE por ahí, que lo pruebe.
Hay otra posibilidad. Antes, el SLES tenía un fichero ARCHIVE.gz (si no recuerdo mal el nombre) en el que venían listados todos los paquetes y su info (vamos, como si haces un rpm -qpil *). Se podría hacer ahí un grep también:
zgrep -iE "(
|license)" ARCHIVE.gz Lo de
es que no me acuerdo cómo aparece en los paquetes rpm cuando haces un: rpm -q[p]i paquete[.rpm]
Descartar paquetes con licencia es sólo uno de los pasos. El más complejo, desde mi punto de vista, sería volver a empaquetar todos los archivos para que no contengan las marcas ("branding") registradas de Novell. Es decir, "detectar" qué hay que eliminar, "quitarlo" y "empaquetarlo" de nuevo. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 14:06 +0200, carlopmart escribió:
Camaleon, todas esas dudas que planteas son muy sencillas de resolver. A nivel técnico no hay problemas. Lo que ha planteado Armin es precisamente el modelo que usa CentOS
a) "Limpieza" de trademarks y temas relacionados: equipo de desarrolladores (en CentOS son 8 personas nada más). Y sabemos lo que se puede eliminar porque hay acceso al código fuente.
b) Realización de las pruebas: el equipo de QA. Aquí cuantas más personas y distintos entornos haya involucrados mejor, pero recordad que la parte más dura ya la ha hecho Novell. Solo hay que asegurarse de que la distro funciona igual a la original, incluyendo los mismos problemas que pueda tener SLES.
c) Recurrir cuando algo falla: pues donde siempre a los foros y las mailing lists. ¿Como creeis que se hacia con CentOS en los inicios?. Sigue siendo igual, aunque es cierto que sí existen empresas dando soporte "oficial".
d) En el caso de una openSLES, yo no meteria nada de OBS. Se trata de que sea un fiel reflejo de la distro original: quiero decir yo no empaquetaria nada que no estuviese en el DVD oficial. Eso sí, se puede crear un repositorio como extras e incluir el software más demandado por los usuarios, vamos el equivalente a universe y multiverse de Ubuntu.
e) Colaboración de Novell: la justita. Quiero decir que si se tiene acceso a la subscripción no se necesita a Novell para nada. La herramienta SMT de SLES ya te descarga todos los fuentes de los updates y los paquetes originales.
Para mi el handicap es averiguar si legalmente se puede hacer y lo demás no tiene problemas ...
Para mí los "handicap" serían varios: - Legalidad del proyecto en entredicho. Si Novell no se pronuncia claramente sobre el tema (no creo que lo haga y si lo hiciera, algo me dice que sería para mal, no para bien :-P), estaríamos en un limbo peligroso porque en cualquier momento podría "atacar" o sacarse un as de la manga y echar abajo todo el proyecto. - Se tendría que seguir el ciclo de versiones de la SLES no de openSUSE. - Los paquetes entre ambas (tal y como ocurre ahora con openSUSE y SLES) no se podrían mezclar (porque no son las mismas versiones y podrían tener efectos secuandarios). - No se podría informar de errores o fallos, no se puede acudir a ningún lado. Si falla un paquete, hay que esperar a que Novell lo saque (si alguien lo reporta) porque nosotros no podríamos dar parte de ese fallo. - Y por último, algo que no me gustó de CentOS, y es que los paquetes que se incluyen son versiones bastante antiguas, algo normal si tenemos en cuenta que las nuevas versiones de Red Hat o de SLES tienen un ciclo más largo. Que los paquetes sean de versiones antiguas no debe ser un problema "per se" (de hecho casi mejor que se así porque suelen estar más probados y con menos bugs), salvo (y ojo que esto es importante) que algo no te funcione (detección de la controladora de disco por ser un chipset moderno) y no tengas opción alguna para solucionarlo porque no se puede reportar con lo cual tendrías que buscarte la vida por tu cuenta. :-/ Me pregunto... no he visto ningún openfate o bugzilla de mejora creado donde se pida el mantenimiento de esos 24 meses que veían siendo los habituales en openSUSE (se ha pedido una LTS o una openSLES pero no he visto ninguno donde se pida mantener el estado anterior). Y me extraña que haya tanto revuelo por el kde como preterminado pero no por este hecho, que -al menos desde mi punto de vista- no beneficia a nadie (ni kdeero, ni gnomero ni xfceedo ni línea-comandero ni usuario de paso...). Me preguntaba si mantendrían el soporte esos 24 meses si así lo deseara la comunidad o si esto se trata de una de esas features "no negociables" >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 2009-08-26 a las 14:06 +0200, carlopmart escribió:
Me pregunto... no he visto ningún openfate o bugzilla de mejora creado donde se pida el mantenimiento de esos 24 meses que veían siendo los habituales en openSUSE (se ha pedido una LTS o una openSLES pero no he visto ninguno donde se pida mantener el estado anterior).
¿No? :\
Y me extraña que haya tanto revuelo por el kde como preterminado pero no por este hecho, que -al menos desde mi punto de vista- no beneficia a nadie (ni kdeero, ni gnomero ni xfceedo ni línea-comandero ni usuario de paso...).
Pues sí. De hecho para mí ha sido la gota que ha colmado mi vaso para decidir dejar de usar OpenSuSE, antes SuSE, desde hace casi _diez_ años... Se dice pronto. Yo no quería, pero, al final me han animado los de Novell a dejar de usarla. Lo que más pena me da no es dejar de usarla, sino que se irá perdiendo el contacto con los de la lista, porque claro, no tienes problemas qué consultar sobre OpenSuSE... pues inconscientemente iré abriendo menos el correo de la lista.
Me preguntaba si mantendrían el soporte esos 24 meses si así lo deseara la comunidad o si esto se trata de una de esas features "no negociables" >:-)
Me temo que no es negociable. Si ellos lo piensan casi en voz alta... OpenSuSE -que no ingresa dinero directamente- le hace la competencia a SLED -que sí ingresa pasta contante y sonante-.
Saludos,
-- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 14:06 +0200, carlopmart escribió:
Camaleon, todas esas dudas que planteas son muy sencillas de resolver. A nivel técnico no hay problemas. Lo que ha planteado Armin es precisamente el modelo que usa CentOS
a) "Limpieza" de trademarks y temas relacionados: equipo de desarrolladores (en CentOS son 8 personas nada más). Y sabemos lo que se puede eliminar porque hay acceso al código fuente.
b) Realización de las pruebas: el equipo de QA. Aquí cuantas más personas y distintos entornos haya involucrados mejor, pero recordad que la parte más dura ya la ha hecho Novell. Solo hay que asegurarse de que la distro funciona igual a la original, incluyendo los mismos problemas que pueda tener SLES.
c) Recurrir cuando algo falla: pues donde siempre a los foros y las mailing lists. ¿Como creeis que se hacia con CentOS en los inicios?. Sigue siendo igual, aunque es cierto que sí existen empresas dando soporte "oficial".
d) En el caso de una openSLES, yo no meteria nada de OBS. Se trata de que sea un fiel reflejo de la distro original: quiero decir yo no empaquetaria nada que no estuviese en el DVD oficial. Eso sí, se puede crear un repositorio como extras e incluir el software más demandado por los usuarios, vamos el equivalente a universe y multiverse de Ubuntu.
e) Colaboración de Novell: la justita. Quiero decir que si se tiene acceso a la subscripción no se necesita a Novell para nada. La herramienta SMT de SLES ya te descarga todos los fuentes de los updates y los paquetes originales.
Para mi el handicap es averiguar si legalmente se puede hacer y lo demás no tiene problemas ...
Para mí los "handicap" serían varios:
- Legalidad del proyecto en entredicho. Si Novell no se pronuncia claramente sobre el tema (no creo que lo haga y si lo hiciera, algo me dice que sería para mal, no para bien :-P), estaríamos en un limbo peligroso porque en cualquier momento podría "atacar" o sacarse un as de la manga y echar abajo todo el proyecto.
- Se tendría que seguir el ciclo de versiones de la SLES no de openSUSE.
- Los paquetes entre ambas (tal y como ocurre ahora con openSUSE y SLES) no se podrían mezclar (porque no son las mismas versiones y podrían tener efectos secuandarios).
- No se podría informar de errores o fallos, no se puede acudir a ningún lado. Si falla un paquete, hay que esperar a que Novell lo saque (si alguien lo reporta) porque nosotros no podríamos dar parte de ese fallo.
Incorrecto. En CentOS recurres a su bugzilla que és público (por cierto, el de RedHat también) y si el fallo es de ellos lo solucionan, si no reporta el equipo de desarrollo a RedHat. Pues lo mismo con una openSLES: el equipo de desarrollo reporta a Novell que para eso pagaría subscripcion. Pero una cosa, esto de que un paquete falla y no tienes a quien reportar y demás que te preocupa en una posible openSLES, ya te pasa con openSuSE y encima pasan de ti como muchs veces habeis dicho en esta lista muchas personas. Por lo menos centOS y RedHat responden, aunque a veces tardan.
- Y por último, algo que no me gustó de CentOS, y es que los paquetes que se incluyen son versiones bastante antiguas, algo normal si tenemos en cuenta que las nuevas versiones de Red Hat o de SLES tienen un ciclo más largo. Que los paquetes sean de versiones antiguas no debe ser un problema "per se" (de hecho casi mejor que se así porque suelen estar más probados y con menos bugs), salvo (y ojo que esto es importante) que algo no te funcione (detección de la controladora de disco por ser un chipset moderno) y no tengas opción alguna para solucionarlo porque no se puede reportar con lo cual tendrías que buscarte la vida por tu cuenta.
:-/
Mec. Error. Esto en CentOS y RedHat sí existe, a nivel de drivers, o sea kernel y nuevas funcionalidades. No te dejes engañar por la versión de kernel que distribuyen. En cada actualización incluyen nuevos drivers de soporte de hardware. Si echas un vistazo a la hcl verás el soporte de hierro nuevo de trinca en su lista. También hay paquetes marcados que "deben" funcionar a ultima release en el momento que sean estables como son firefox, openofffice ... Por supuesto olvidate de temas multimedia y demás. Recordad: Enterprise, encaradas a empresa.
Me pregunto... no he visto ningún openfate o bugzilla de mejora creado donde se pida el mantenimiento de esos 24 meses que veían siendo los habituales en openSUSE (se ha pedido una LTS o una openSLES pero no he visto ninguno donde se pida mantener el estado anterior).
Lógico: crisis -> menos recursos -> mas barato.
Y me extraña que haya tanto revuelo por el kde como preterminado pero no por este hecho, que -al menos desde mi punto de vista- no beneficia a nadie (ni kdeero, ni gnomero ni xfceedo ni línea-comandero ni usuario de paso...).
Me preguntaba si mantendrían el soporte esos 24 meses si así lo deseara la comunidad o si esto se trata de una de esas features "no negociables" >:-)
Saludos,
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 15:35 +0200, carlopmart escribió:
Camaleón wrote:
Para mí los "handicap" serían varios:
- Legalidad del proyecto en entredicho. Si Novell no se pronuncia claramente sobre el tema (no creo que lo haga y si lo hiciera, algo me dice que sería para mal, no para bien :-P), estaríamos en un limbo peligroso porque en cualquier momento podría "atacar" o sacarse un as de la manga y echar abajo todo el proyecto. - Se tendría que seguir el ciclo de versiones de la SLES no de openSUSE. - Los paquetes entre ambas (tal y como ocurre ahora con openSUSE y SLES) no se podrían mezclar (porque no son las mismas versiones y podrían tener efectos secuandarios). - No se podría informar de errores o fallos, no se puede acudir a ningún lado. Si falla un paquete, hay que esperar a que Novell lo saque (si alguien lo reporta) porque nosotros no podríamos dar parte de ese fallo.
Incorrecto. En CentOS recurres a su bugzilla que és público (por cierto, el de RedHat también) y si el fallo es de ellos lo solucionan, si no reporta el equipo de desarrollo a RedHat. Pues lo mismo con una openSLES: el equipo de desarrollo reporta a Novell que para eso pagaría subscripcion.
Los bugzillas de SLES no son públicos. Quien reporta no vería nada, tendría que canalizarse todo a través del que tenga "crédito" con Novell y si ya de por sí es lento, añadir otro elemento más a la cadena sería muy incómodo. Además, los de Novell te podrían decir "O.k., mandamos un técnico a su oficina, para que puedan revisar el problema in-situ" ¿y qué hacemos, enviamos el bastidor a la casa del intermediario openSLESero, en Utah? >:-)
Pero una cosa, esto de que un paquete falla y no tienes a quien reportar y demás que te preocupa en una posible openSLES, ya te pasa con openSuSE y encima pasan de ti como muchs veces habeis dicho en esta lista muchas personas. Por lo menos centOS y RedHat responden, aunque a veces tardan.
Los problemas gordos (serios) en el bugzilla no van tan mal de tiempos... sólo he tenido un par de fallos "serios" (relacionados con el kernel) y se gestionaron en un tiempo prudencial (menos de 1 semana).
- Y por último, algo que no me gustó de CentOS, y es que los paquetes que se incluyen son versiones bastante antiguas, algo normal si tenemos en cuenta que las nuevas versiones de Red Hat o de SLES tienen un ciclo más largo. Que los paquetes sean de versiones antiguas no debe ser un problema "per se" (de hecho casi mejor que se así porque suelen estar más probados y con menos bugs), salvo (y ojo que esto es importante) que algo no te funcione (detección de la controladora de disco por ser un chipset moderno) y no tengas opción alguna para solucionarlo porque no se puede reportar con lo cual tendrías que buscarte la vida por tu cuenta. :-/
Mec. Error. Esto en CentOS y RedHat sí existe, a nivel de drivers, o sea kernel y nuevas funcionalidades. No te dejes engañar por la versión de kernel que distribuyen. En cada actualización incluyen nuevos drivers de soporte de hardware. Si echas un vistazo a la hcl verás el soporte de hierro nuevo de trinca en su lista.
También hay paquetes marcados que "deben" funcionar a ultima release en el momento que sean estables como son firefox, openofffice ... Por supuesto olvidate de temas multimedia y demás. Recordad: Enterprise, encaradas a empresa.
Pero para instalar esos parches de mejora tienes que tener un sistema base funcionando. Si yo descargo la SLES 11 (que no tiene ningún SP sacado aún, creo...) y no me detecta la controladora raid ¿qué hago? :-)
Me pregunto... no he visto ningún openfate o bugzilla de mejora creado donde se pida el mantenimiento de esos 24 meses que veían siendo los habituales en openSUSE (se ha pedido una LTS o una openSLES pero no he visto ninguno donde se pida mantener el estado anterior).
Lógico: crisis -> menos recursos -> mas barato.
Entonces, ¿debemos entender que este tipo de "anuncios" no son más que una "herramienta de distracción" (aka: tomadura de pelo)? :-) [opensuse-project] More Support for the openSUSE Project http://lists.opensuse.org/opensuse-project/2009-08/msg00455.html Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 15:35 +0200, carlopmart escribió:
Camaleón wrote:
Para mí los "handicap" serían varios:
- Legalidad del proyecto en entredicho. Si Novell no se pronuncia claramente sobre el tema (no creo que lo haga y si lo hiciera, algo me dice que sería para mal, no para bien :-P), estaríamos en un limbo peligroso porque en cualquier momento podría "atacar" o sacarse un as de la manga y echar abajo todo el proyecto. - Se tendría que seguir el ciclo de versiones de la SLES no de openSUSE. - Los paquetes entre ambas (tal y como ocurre ahora con openSUSE y SLES) no se podrían mezclar (porque no son las mismas versiones y podrían tener efectos secuandarios). - No se podría informar de errores o fallos, no se puede acudir a ningún lado. Si falla un paquete, hay que esperar a que Novell lo saque (si alguien lo reporta) porque nosotros no podríamos dar parte de ese fallo. Incorrecto. En CentOS recurres a su bugzilla que és público (por cierto, el de RedHat también) y si el fallo es de ellos lo solucionan, si no reporta el equipo de desarrollo a RedHat. Pues lo mismo con una openSLES: el equipo de desarrollo reporta a Novell que para eso pagaría subscripcion.
Los bugzillas de SLES no son públicos. Quien reporta no vería nada, tendría que canalizarse todo a través del que tenga "crédito" con Novell y si ya de por sí es lento, añadir otro elemento más a la cadena sería muy incómodo.
No tiene porque si hay un grupo de personas que tienen el control. Pero dá igual, es la misma situación en la que está CentOS. Cuando alguien reporta un bugzilla de interés común será liberado bajo parche. Si es un bugzilla concreto para tu infraestructura, es normal que solo lo recibas tú. Con Red Hat pasa igual: si tu problema es solo tuyo te lo solucionan a tí y NO lo hacen público. ¿Cual es el problema??. No hay que perder de vista que aquí se habla de una distro hecha por personas a las que les gusta SuSE, no por una empresa. Con openSuSE estás igual o peor ¿no?
Además, los de Novell te podrían decir "O.k., mandamos un técnico a su oficina, para que puedan revisar el problema in-situ" ¿y qué hacemos, enviamos el bastidor a la casa del intermediario openSLESero, en Utah? >:-)
Mande?? ¿Alguien ha tenido un problema de tal magnitud que Novell le haya tenido que enviar un técnico, por ejemplo en España?? Yo llevo a muchos clientes (grandes y medianos) con Red Hat/CentOS en sus sistemas de test, pre-producción y producción y en ocasiones han surgido problemas muy serios y en ningún caso ha hecho falta que viniese un técnico de Red Hat al cliente. Repito: openSLES DEBE ser una distro hecha por personas a las que les gusta tener algo estable, robusto y con soporte largo. Y si la usas para sistemas de producción asumes ciertas cosas. Yo tendría más miedo de poner una openSuSE en producción que una openSLES y más de uno de vosotros tiene a openSuSE en producción ¿no?.
Pero una cosa, esto de que un paquete falla y no tienes a quien reportar y demás que te preocupa en una posible openSLES, ya te pasa con openSuSE y encima pasan de ti como muchs veces habeis dicho en esta lista muchas personas. Por lo menos centOS y RedHat responden, aunque a veces tardan.
Los problemas gordos (serios) en el bugzilla no van tan mal de tiempos... sólo he tenido un par de fallos "serios" (relacionados con el kernel) y se gestionaron en un tiempo prudencial (menos de 1 semana).
Pues con openSLES igual, o mejor, porque el problema lo soluciona Novell. Tu solo tienes que "limpiar" el paquete, probarlo y liberar el parche.
- Y por último, algo que no me gustó de CentOS, y es que los paquetes que se incluyen son versiones bastante antiguas, algo normal si tenemos en cuenta que las nuevas versiones de Red Hat o de SLES tienen un ciclo más largo. Que los paquetes sean de versiones antiguas no debe ser un problema "per se" (de hecho casi mejor que se así porque suelen estar más probados y con menos bugs), salvo (y ojo que esto es importante) que algo no te funcione (detección de la controladora de disco por ser un chipset moderno) y no tengas opción alguna para solucionarlo porque no se puede reportar con lo cual tendrías que buscarte la vida por tu cuenta. :-/ Mec. Error. Esto en CentOS y RedHat sí existe, a nivel de drivers, o sea kernel y nuevas funcionalidades. No te dejes engañar por la versión de kernel que distribuyen. En cada actualización incluyen nuevos drivers de soporte de hardware. Si echas un vistazo a la hcl verás el soporte de hierro nuevo de trinca en su lista.
También hay paquetes marcados que "deben" funcionar a ultima release en el momento que sean estables como son firefox, openofffice ... Por supuesto olvidate de temas multimedia y demás. Recordad: Enterprise, encaradas a empresa.
Pero para instalar esos parches de mejora tienes que tener un sistema base funcionando. Si yo descargo la SLES 11 (que no tiene ningún SP sacado aún, creo...) y no me detecta la controladora raid ¿qué hago? :-)
Esperar como esperas con openSuSE. Al final si es una controladora de un fabricante reconocido, te darán el driver.
Me pregunto... no he visto ningún openfate o bugzilla de mejora creado donde se pida el mantenimiento de esos 24 meses que veían siendo los habituales en openSUSE (se ha pedido una LTS o una openSLES pero no he visto ninguno donde se pida mantener el estado anterior). Lógico: crisis -> menos recursos -> mas barato.
Entonces, ¿debemos entender que este tipo de "anuncios" no son más que una "herramienta de distracción" (aka: tomadura de pelo)? :-)
[opensuse-project] More Support for the openSUSE Project http://lists.opensuse.org/opensuse-project/2009-08/msg00455.html
No, significa optimización de los recursos y mayor provecho de los mismos ...
Saludos,
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 16:50 +0200, carlopmart escribió:
Camaleón wrote:
Incorrecto. En CentOS recurres a su bugzilla que és público (por cierto, el de RedHat también) y si el fallo es de ellos lo solucionan, si no reporta el equipo de desarrollo a RedHat. Pues lo mismo con una openSLES: el equipo de desarrollo reporta a Novell que para eso pagaría subscripcion.
Los bugzillas de SLES no son públicos. Quien reporta no vería nada, tendría que canalizarse todo a través del que tenga "crédito" con Novell y si ya de por sí es lento, añadir otro elemento más a la cadena sería muy incómodo.
No tiene porque si hay un grupo de personas que tienen el control. Pero dá igual, es la misma situación en la que está CentOS. Cuando alguien reporta un bugzilla de interés común será liberado bajo parche.
¿Y quién lo libera, CentOS o Rad Hat? Porque en el caso que nos atañe, Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor, no "a través" de alguien con contrato en vigor.
Si es un bugzilla concreto para tu infraestructura, es normal que solo lo recibas tú. Con Red Hat pasa igual: si tu problema es solo tuyo te lo solucionan a tí y NO lo hacen público. ¿Cual es el problema??.
No hay que perder de vista que aquí se habla de una distro hecha por personas a las que les gusta SuSE, no por una empresa. Con openSuSE estás igual o peor ¿no?
No, con openSUSE si tengo un problema, reporto. Si es serio, seguramente me den a probar algún paquete prepado por ellos para que lo pruebe y les diga si el fallos se soluciona. Si es así, lo sacarán en la siguiente actualización.
Además, los de Novell te podrían decir "O.k., mandamos un técnico a su oficina, para que puedan revisar el problema in-situ" ¿y qué hacemos, enviamos el bastidor a la casa del intermediario openSLESero, en Utah?
:-)
Mande?? ¿Alguien ha tenido un problema de tal magnitud que Novell le haya tenido que enviar un técnico, por ejemplo en España?? Yo llevo a muchos clientes (grandes y medianos) con Red Hat/CentOS en sus sistemas de test, pre-producción y producción y en ocasiones han surgido problemas muy serios y en ningún caso ha hecho falta que viniese un técnico de Red Hat al cliente.
Porque Novell "sabe" que tus clientes tienen contratos en regla, por eso no hacen preguntas de ese tipo >:-)
Repito: openSLES DEBE ser una distro hecha por personas a las que les gusta tener algo estable, robusto y con soporte largo. Y si la usas para sistemas de producción asumes ciertas cosas. Yo tendría más miedo de poner una openSuSE en producción que una openSLES y más de uno de vosotros tiene a openSuSE en producción ¿no?.
No, para nada ¿por qué? Si hay algún problema, puedo informar del fallo, sin temor a que Novell descubra nada ni tome cartas en el asunto. Si hay algún problema, puedo probar algún kernel o paquete que los desarrolladores me den "exprofeso", para mi problema, para que lo pruebe.
Pero una cosa, esto de que un paquete falla y no tienes a quien reportar y demás que te preocupa en una posible openSLES, ya te pasa con openSuSE y encima pasan de ti como muchs veces habeis dicho en esta lista muchas personas. Por lo menos centOS y RedHat responden, aunque a veces tardan.
Los problemas gordos (serios) en el bugzilla no van tan mal de tiempos... sólo he tenido un par de fallos "serios" (relacionados con el kernel) y se gestionaron en un tiempo prudencial (menos de 1 semana).
Pues con openSLES igual, o mejor, porque el problema lo soluciona Novell. Tu solo tienes que "limpiar" el paquete, probarlo y liberar el parche.
¡Es será si Novell te lo quiere solucionar! >:-) Novell no es tan rápida sacando parches como openSUSE, ten en cuenta que paquete o parche que saque tiene que probarlo y certificarlo para todas las instalaciones.
Mec. Error. Esto en CentOS y RedHat sí existe, a nivel de drivers, o sea kernel y nuevas funcionalidades. No te dejes engañar por la versión de kernel que distribuyen. En cada actualización incluyen nuevos drivers de soporte de hardware. Si echas un vistazo a la hcl verás el soporte de hierro nuevo de trinca en su lista.
También hay paquetes marcados que "deben" funcionar a ultima release en el momento que sean estables como son firefox, openofffice ... Por supuesto olvidate de temas multimedia y demás. Recordad: Enterprise, encaradas a empresa. Pero para instalar esos parches de mejora tienes que tener un sistema base funcionando. Si yo descargo la SLES 11 (que no tiene ningún SP sacado aún, creo...) y no me detecta la controladora raid ¿qué hago? :-)
Esperar como esperas con openSuSE. Al final si es una controladora de un fabricante reconocido, te darán el driver.
Te recuerdo que la espera en openSUSE es de 8 meses (el tiempo que tardan en sacar una nueva versión con paquetes actualizados, más controladores, etc...), la de Novell es de ¿3 años entre versiones? >:-) Es decir, o lo tenemos bien "agarrado" el tema del contrato con Novell o nos pueden dejar k.o.
Me pregunto... no he visto ningún openfate o bugzilla de mejora creado donde se pida el mantenimiento de esos 24 meses que veían siendo los habituales en openSUSE (se ha pedido una LTS o una openSLES pero no he visto ninguno donde se pida mantener el estado anterior).
Lógico: crisis -> menos recursos -> mas barato.
Entonces, ¿debemos entender que este tipo de "anuncios" no son más que una "herramienta de distracción" (aka: tomadura de pelo)? :-) [opensuse-project] More Support for the openSUSE Project http://lists.opensuse.org/opensuse-project/2009-08/msg00455.html
No, significa optimización de los recursos y mayor provecho de los mismos
¿Dices que "más soporte para openSUSE = menos soporte para las versiones"? ¿Y cómo se come eso? >:-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 16:50 +0200, carlopmart escribió:
Camaleón wrote:
Incorrecto. En CentOS recurres a su bugzilla que és público (por cierto, el de RedHat también) y si el fallo es de ellos lo solucionan, si no reporta el equipo de desarrollo a RedHat. Pues lo mismo con una openSLES: el equipo de desarrollo reporta a Novell que para eso pagaría subscripcion.
Los bugzillas de SLES no son públicos. Quien reporta no vería nada, tendría que canalizarse todo a través del que tenga "crédito" con Novell y si ya de por sí es lento, añadir otro elemento más a la cadena sería muy incómodo. No tiene porque si hay un grupo de personas que tienen el control. Pero dá igual, es la misma situación en la que está CentOS. Cuando alguien reporta un bugzilla de interés común será liberado bajo parche.
¿Y quién lo libera, CentOS o Rad Hat? Porque en el caso que nos atañe, Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor, no "a través" de alguien con contrato en vigor.
CentOS solo libera si el error es suyo. Si no, CentOS no libera nada hasta que lo haga Red Hat. Y en 4 años usando CentOS eso solo ha ocurrido 2 veces: un error de la propia CentOS. Sobre "Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor", no me lo creo. Si alguien en la mailing list de sles o en los forums de Novell empieza a hacer "ruido" con un problema que tiene y no está reportado en bugzilla y van apareciendo más usuarios con ese mismo problema, Novell actuará de "oficio": arreglará el problema sin un bugzilla abierto, o inclusive lo abrirán ellos mismso si su protocolo interno se lo recomienda. Aquí estamos hablando de modelos Enterprise, aka negocio, aka $$$$. ¿Tu crees que si un usuario empieza a tener problemas de mal funcionamiento de ssh (y que esa situación solo se dá en SLES y no en otras distros) y lo dice en los foros o mailing list de SLES no va a haber un técnico de Novell al tanto del problema?? Créeme lo estará.
Si es un bugzilla concreto para tu infraestructura, es normal que solo lo recibas tú. Con Red Hat pasa igual: si tu problema es solo tuyo te lo solucionan a tí y NO lo hacen público. ¿Cual es el problema??.
No hay que perder de vista que aquí se habla de una distro hecha por personas a las que les gusta SuSE, no por una empresa. Con openSuSE estás igual o peor ¿no?
No, con openSUSE si tengo un problema, reporto. Si es serio, seguramente me den a probar algún paquete prepado por ellos para que lo pruebe y les diga si el fallos se soluciona. Si es así, lo sacarán en la siguiente actualización.
Correcto, pero es que eso te lo va a hacer Novell gratis en referencia a openSLES, porque si es un problema en las SLES de rebote quedará arreglado en la openSLES. Sigo sin ver el problema.
:-) Mande?? ¿Alguien ha tenido un problema de tal magnitud que Novell le haya tenido que enviar un técnico, por ejemplo en España?? Yo llevo a muchos clientes (grandes y medianos) con Red Hat/CentOS en sus sistemas de test,
Además, los de Novell te podrían decir "O.k., mandamos un técnico a su oficina, para que puedan revisar el problema in-situ" ¿y qué hacemos, enviamos el bastidor a la casa del intermediario openSLESero, en Utah? pre-producción y producción y en ocasiones han surgido problemas muy serios y en ningún caso ha hecho falta que viniese un técnico de Red Hat al cliente.
Porque Novell "sabe" que tus clientes tienen contratos en regla, por eso no hacen preguntas de ese tipo >:-)
Pues igual pasará con el binomio openSLES/SLES.
Repito: openSLES DEBE ser una distro hecha por personas a las que les gusta tener algo estable, robusto y con soporte largo. Y si la usas para sistemas de producción asumes ciertas cosas. Yo tendría más miedo de poner una openSuSE en producción que una openSLES y más de uno de vosotros tiene a openSuSE en producción ¿no?.
No, para nada ¿por qué? Si hay algún problema, puedo informar del fallo, sin temor a que Novell descubra nada ni tome cartas en el asunto. Si hay algún problema, puedo probar algún kernel o paquete que los desarrolladores me den "exprofeso", para mi problema, para que lo pruebe.
Pues igual pasa con CentOS. Y pasará con openSLES. En CentOS hay un repositorio de software expiremental que puedes probar cuanto quieras para ver si tu problema se soluciona. Si es así, el equipo de CentOS reporta a Red Hat y este lo soluciona. La cadena es la misma para openSLES. Sigo sin ver donde ves el problema....
Pero una cosa, esto de que un paquete falla y no tienes a quien reportar y demás que te preocupa en una posible openSLES, ya te pasa con openSuSE y encima pasan de ti como muchs veces habeis dicho en esta lista muchas personas. Por lo menos centOS y RedHat responden, aunque a veces tardan.
Los problemas gordos (serios) en el bugzilla no van tan mal de tiempos... sólo he tenido un par de fallos "serios" (relacionados con el kernel) y se gestionaron en un tiempo prudencial (menos de 1 semana). Pues con openSLES igual, o mejor, porque el problema lo soluciona Novell. Tu solo tienes que "limpiar" el paquete, probarlo y liberar el parche.
¡Es será si Novell te lo quiere solucionar! >:-) Novell no es tan rápida sacando parches como openSUSE, ten en cuenta que paquete o parche que saque tiene que probarlo y certificarlo para todas las instalaciones.
Y Red Hat igual ¿o que esperabas? Y si hay un problema de verdad, a Novell no le queda otro remedio que solucionarlo ... O no te entiendo, o mejor ponme un ejemplo ...
Mec. Error. Esto en CentOS y RedHat sí existe, a nivel de drivers, o sea kernel y nuevas funcionalidades. No te dejes engañar por la versión de kernel que distribuyen. En cada actualización incluyen nuevos drivers de soporte de hardware. Si echas un vistazo a la hcl verás el soporte de hierro nuevo de trinca en su lista.
También hay paquetes marcados que "deben" funcionar a ultima release en el momento que sean estables como son firefox, openofffice ... Por supuesto olvidate de temas multimedia y demás. Recordad: Enterprise, encaradas a empresa. Pero para instalar esos parches de mejora tienes que tener un sistema base funcionando. Si yo descargo la SLES 11 (que no tiene ningún SP sacado aún, creo...) y no me detecta la controladora raid ¿qué hago? :-) Esperar como esperas con openSuSE. Al final si es una controladora de un fabricante reconocido, te darán el driver.
Te recuerdo que la espera en openSUSE es de 8 meses (el tiempo que tardan en sacar una nueva versión con paquetes actualizados, más controladores, etc...), la de Novell es de ¿3 años entre versiones? >:-)
Es decir, o lo tenemos bien "agarrado" el tema del contrato con Novell o nos pueden dejar k.o.
No me creo que un driver nuevo, Novell tarde 3 años en sacarlo si es un fabricante como LSI, Dell, HP, etc ... Ahora bien si el fabricante es "foo", entonces si ...
Me pregunto... no he visto ningún openfate o bugzilla de mejora creado donde se pida el mantenimiento de esos 24 meses que veían siendo los habituales en openSUSE (se ha pedido una LTS o una openSLES pero no he visto ninguno donde se pida mantener el estado anterior).
Lógico: crisis -> menos recursos -> mas barato.
Entonces, ¿debemos entender que este tipo de "anuncios" no son más que una "herramienta de distracción" (aka: tomadura de pelo)? :-) [opensuse-project] More Support for the openSUSE Project http://lists.opensuse.org/opensuse-project/2009-08/msg00455.html No, significa optimización de los recursos y mayor provecho de los mismos
¿Dices que "más soporte para openSUSE = menos soporte para las versiones"? ¿Y cómo se come eso? >:-?
Saludos,
¿Y yo he dicho eso?? Yo me refiero a la reducción del tiempo de mantenimiento entre las distintas releases de openSuSE ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Creo que están o estamos discutiendo sobre algo hipotético o cuya
ocurrencia es muy baja como para que sea un escollo que impida al
proyecto salir a la luz, tampoco digo que no sea importante.
Por ejemplo tengo 5 servidores corriendo con SLES9 (1), SLES10(3) y
centOS (1) todos corriendo en hardware de IBM, desde un x232 hasta los
nuevos x3650 ninguno me ha dado problemas con hardware (drivers)
tampoco he tenido problemas de compatibilidad de paquetes con las
aplicaciones.
Así que no veo necesario centrarse demasiado en posibles problemas con
los parches que hipotéticamente necesitarían los hipotéticos usuarios
de la hipotética openSLES... ;-)
Mas bien seria interesante que el proyecto despegue y si después se
estrella por falta de comunidad pues bien... o por una traba que
consiga imponer NOVELL , algo absurdo desde mi punto de vista, pues
bien...
Un punto que tal ves seria interesante también es la de ofrecer como
un repositorio los paquetes SDK que actualmente son 2 DVD si bien
serían muchos paquetes a mantener, ofrecerlos como una repo bajo
responsabilidad del que lo utiliza no estaría nada mal y si la
comunidad crece pues también se podrían agregar como repo "oficial" de
openSLES :-D
Saludos!
El 26 de agosto de 2009 11:39, carlopmart
Camaleón wrote:
El 2009-08-26 a las 16:50 +0200, carlopmart escribió:
Camaleón wrote:
Incorrecto. En CentOS recurres a su bugzilla que és público (por cierto, el de RedHat también) y si el fallo es de ellos lo solucionan, si no reporta el equipo de desarrollo a RedHat. Pues lo mismo con una openSLES: el equipo de desarrollo reporta a Novell que para eso pagaría subscripcion.
Los bugzillas de SLES no son públicos. Quien reporta no vería nada, tendría que canalizarse todo a través del que tenga "crédito" con Novell y si ya de por sí es lento, añadir otro elemento más a la cadena sería muy incómodo.
No tiene porque si hay un grupo de personas que tienen el control. Pero dá igual, es la misma situación en la que está CentOS. Cuando alguien reporta un bugzilla de interés común será liberado bajo parche.
¿Y quién lo libera, CentOS o Rad Hat? Porque en el caso que nos atañe, Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor, no "a través" de alguien con contrato en vigor.
CentOS solo libera si el error es suyo. Si no, CentOS no libera nada hasta que lo haga Red Hat. Y en 4 años usando CentOS eso solo ha ocurrido 2 veces: un error de la propia CentOS.
Sobre "Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor", no me lo creo. Si alguien en la mailing list de sles o en los forums de Novell empieza a hacer "ruido" con un problema que tiene y no está reportado en bugzilla y van apareciendo más usuarios con ese mismo problema, Novell actuará de "oficio": arreglará el problema sin un bugzilla abierto, o inclusive lo abrirán ellos mismso si su protocolo interno se lo recomienda. Aquí estamos hablando de modelos Enterprise, aka negocio, aka $$$$. ¿Tu crees que si un usuario empieza a tener problemas de mal funcionamiento de ssh (y que esa situación solo se dá en SLES y no en otras distros) y lo dice en los foros o mailing list de SLES no va a haber un técnico de Novell al tanto del problema?? Créeme lo estará.
Si es un bugzilla concreto para tu infraestructura, es normal que solo lo recibas tú. Con Red Hat pasa igual: si tu problema es solo tuyo te lo solucionan a tí y NO lo hacen público. ¿Cual es el problema??.
No hay que perder de vista que aquí se habla de una distro hecha por personas a las que les gusta SuSE, no por una empresa. Con openSuSE estás igual o peor ¿no?
No, con openSUSE si tengo un problema, reporto. Si es serio, seguramente me den a probar algún paquete prepado por ellos para que lo pruebe y les diga si el fallos se soluciona. Si es así, lo sacarán en la siguiente actualización.
Correcto, pero es que eso te lo va a hacer Novell gratis en referencia a openSLES, porque si es un problema en las SLES de rebote quedará arreglado en la openSLES. Sigo sin ver el problema.
Además, los de Novell te podrían decir "O.k., mandamos un técnico a su oficina, para que puedan revisar el problema in-situ" ¿y qué hacemos, enviamos el bastidor a la casa del intermediario openSLESero, en Utah?
:-)
Mande?? ¿Alguien ha tenido un problema de tal magnitud que Novell le haya tenido que enviar un técnico, por ejemplo en España?? Yo llevo a muchos clientes (grandes y medianos) con Red Hat/CentOS en sus sistemas de test, pre-producción y producción y en ocasiones han surgido problemas muy serios y en ningún caso ha hecho falta que viniese un técnico de Red Hat al cliente.
Porque Novell "sabe" que tus clientes tienen contratos en regla, por eso no hacen preguntas de ese tipo >:-)
Pues igual pasará con el binomio openSLES/SLES.
Repito: openSLES DEBE ser una distro hecha por personas a las que les gusta tener algo estable, robusto y con soporte largo. Y si la usas para sistemas de producción asumes ciertas cosas. Yo tendría más miedo de poner una openSuSE en producción que una openSLES y más de uno de vosotros tiene a openSuSE en producción ¿no?.
No, para nada ¿por qué? Si hay algún problema, puedo informar del fallo, sin temor a que Novell descubra nada ni tome cartas en el asunto. Si hay algún problema, puedo probar algún kernel o paquete que los desarrolladores me den "exprofeso", para mi problema, para que lo pruebe.
Pues igual pasa con CentOS. Y pasará con openSLES. En CentOS hay un repositorio de software expiremental que puedes probar cuanto quieras para ver si tu problema se soluciona. Si es así, el equipo de CentOS reporta a Red Hat y este lo soluciona. La cadena es la misma para openSLES. Sigo sin ver donde ves el problema....
Pero una cosa, esto de que un paquete falla y no tienes a quien reportar y demás que te preocupa en una posible openSLES, ya te pasa con openSuSE y encima pasan de ti como muchs veces habeis dicho en esta lista muchas personas. Por lo menos centOS y RedHat responden, aunque a veces tardan.
Los problemas gordos (serios) en el bugzilla no van tan mal de tiempos... sólo he tenido un par de fallos "serios" (relacionados con el kernel) y se gestionaron en un tiempo prudencial (menos de 1 semana).
Pues con openSLES igual, o mejor, porque el problema lo soluciona Novell. Tu solo tienes que "limpiar" el paquete, probarlo y liberar el parche.
¡Es será si Novell te lo quiere solucionar! >:-) Novell no es tan rápida sacando parches como openSUSE, ten en cuenta que paquete o parche que saque tiene que probarlo y certificarlo para todas las instalaciones.
Y Red Hat igual ¿o que esperabas? Y si hay un problema de verdad, a Novell no le queda otro remedio que solucionarlo ... O no te entiendo, o mejor ponme un ejemplo ...
Mec. Error. Esto en CentOS y RedHat sí existe, a nivel de drivers, o sea kernel y nuevas funcionalidades. No te dejes engañar por la versión de kernel que distribuyen. En cada actualización incluyen nuevos drivers de soporte de hardware. Si echas un vistazo a la hcl verás el soporte de hierro nuevo de trinca en su lista.
También hay paquetes marcados que "deben" funcionar a ultima release en el momento que sean estables como son firefox, openofffice ... Por supuesto olvidate de temas multimedia y demás. Recordad: Enterprise, encaradas a empresa.
Pero para instalar esos parches de mejora tienes que tener un sistema base funcionando. Si yo descargo la SLES 11 (que no tiene ningún SP sacado aún, creo...) y no me detecta la controladora raid ¿qué hago? :-)
Esperar como esperas con openSuSE. Al final si es una controladora de un fabricante reconocido, te darán el driver.
Te recuerdo que la espera en openSUSE es de 8 meses (el tiempo que tardan en sacar una nueva versión con paquetes actualizados, más controladores, etc...), la de Novell es de ¿3 años entre versiones? >:-)
Es decir, o lo tenemos bien "agarrado" el tema del contrato con Novell o nos pueden dejar k.o.
No me creo que un driver nuevo, Novell tarde 3 años en sacarlo si es un fabricante como LSI, Dell, HP, etc ... Ahora bien si el fabricante es "foo", entonces si ...
Me pregunto... no he visto ningún openfate o bugzilla de mejora creado donde se pida el mantenimiento de esos 24 meses que veían siendo los habituales en openSUSE (se ha pedido una LTS o una openSLES pero no he visto ninguno donde se pida mantener el estado anterior).
Lógico: crisis -> menos recursos -> mas barato.
Entonces, ¿debemos entender que este tipo de "anuncios" no son más que una "herramienta de distracción" (aka: tomadura de pelo)? :-) [opensuse-project] More Support for the openSUSE Project http://lists.opensuse.org/opensuse-project/2009-08/msg00455.html
No, significa optimización de los recursos y mayor provecho de los mismos
¿Dices que "más soporte para openSUSE = menos soporte para las versiones"? ¿Y cómo se come eso? >:-?
Saludos,
¿Y yo he dicho eso?? Yo me refiero a la reducción del tiempo de mantenimiento entre las distintas releases de openSuSE ...
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 11:57 -0400, Armin Díaz Argaña escribió:
Creo que están o estamos discutiendo sobre algo hipotético o cuya ocurrencia es muy baja como para que sea un escollo que impida al proyecto salir a la luz, tampoco digo que no sea importante.
"Aquél que prevé es dueño de sus días" :-)
Por ejemplo tengo 5 servidores corriendo con SLES9 (1), SLES10(3) y centOS (1) todos corriendo en hardware de IBM, desde un x232 hasta los nuevos x3650 ninguno me ha dado problemas con hardware (drivers) tampoco he tenido problemas de compatibilidad de paquetes con las aplicaciones.
Así que no veo necesario centrarse demasiado en posibles problemas con los parches que hipotéticamente necesitarían los hipotéticos usuarios de la hipotética openSLES... ;-)
Pues yo creo que sí es importante. Son cosas que hay que tener en cuenta, antes, durante y después. Si no está todo prístinamente claro, yo no instalaría esa versión, no me puedo arriesgar a tener que quitarla a los 6 meses :-(
Mas bien seria interesante que el proyecto despegue y si después se estrella por falta de comunidad pues bien... o por una traba que consiga imponer NOVELL , algo absurdo desde mi punto de vista, pues bien...
Lo que consideras "absurdo" debe ser, precisamente, uno de los principales motivos por los cuales aún no existe ese proyecto :-)
Un punto que tal ves seria interesante también es la de ofrecer como un repositorio los paquetes SDK que actualmente son 2 DVD si bien serían muchos paquetes a mantener, ofrecerlos como una repo bajo responsabilidad del que lo utiliza no estaría nada mal y si la comunidad crece pues también se podrían agregar como repo "oficial" de openSLES :-D
No me convence. Para instalarlo en mi casa, vale. Para instalarlo en los servidores, pues no :-/ Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 26 de agosto de 2009 12:18, Camaleón
El 2009-08-26 a las 11:57 -0400, Armin Díaz Argaña escribió:
Creo que están o estamos discutiendo sobre algo hipotético o cuya ocurrencia es muy baja como para que sea un escollo que impida al proyecto salir a la luz, tampoco digo que no sea importante.
"Aquél que prevé es dueño de sus días" :-)
Por ejemplo tengo 5 servidores corriendo con SLES9 (1), SLES10(3) y centOS (1) todos corriendo en hardware de IBM, desde un x232 hasta los nuevos x3650 ninguno me ha dado problemas con hardware (drivers) tampoco he tenido problemas de compatibilidad de paquetes con las aplicaciones.
Así que no veo necesario centrarse demasiado en posibles problemas con los parches que hipotéticamente necesitarían los hipotéticos usuarios de la hipotética openSLES... ;-)
Pues yo creo que sí es importante. Son cosas que hay que tener en cuenta, antes, durante y después. Si no está todo prístinamente claro, yo no instalaría esa versión, no me puedo arriesgar a tener que quitarla a los 6 meses :-(
Es tu elección, en el caso mio si lo haría, no en producción inicialmente, pero si el proyecto madura como centOS seguro que si... pero para eso debe haber gente voluntaria que apoye el proyecto, se anime a probar para colaborar.
Mas bien seria interesante que el proyecto despegue y si después se estrella por falta de comunidad pues bien... o por una traba que consiga imponer NOVELL , algo absurdo desde mi punto de vista, pues bien...
Lo que consideras "absurdo" debe ser, precisamente, uno de los principales motivos por los cuales aún no existe ese proyecto :-)
En mi opinión es muy remoto que NOVELL tenga alguna argucia legal que pueda trabar el proyecto, que llegaria al absurdo, ya que todos o casi todos los paquetes SLES de algún modo están infectados con GPL principal razon por la cual puedes obtener SLES sin mayores trabas y lo puedes instalar "n" veces donde y como quieras.
Un punto que tal ves seria interesante también es la de ofrecer como un repositorio los paquetes SDK que actualmente son 2 DVD si bien serían muchos paquetes a mantener, ofrecerlos como una repo bajo responsabilidad del que lo utiliza no estaría nada mal y si la comunidad crece pues también se podrían agregar como repo "oficial" de openSLES :-D
No me convence.
Para instalarlo en mi casa, vale. Para instalarlo en los servidores, pues no :-/
Pues si tienes equipo de desarrollo hasta te exigirán tener paquetes SDK pues en esos paquetes hay motón de herramientas, librerías y muchos paquetes que no vienen de serie en SLES, y que están probados para SLES. Sinceramente muy útil...
Saludos,
-- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 17:39 +0200, carlopmart escribió:
Camaleón wrote:
¿Y quién lo libera, CentOS o Rad Hat? Porque en el caso que nos atañe, Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor, no "a través" de alguien con contrato en vigor.
CentOS solo libera si el error es suyo. Si no, CentOS no libera nada hasta que lo haga Red Hat. Y en 4 años usando CentOS eso solo ha ocurrido 2 veces: un error de la propia CentOS.
Pues eso te digo... si el error no es suyo (que es de Red Hat o que viene upstream) ¿qué hacemos? :-/
Sobre "Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor", no me lo creo.
Jupe, pues ya me dirás... salvo que empiece a recibir el mismo informe de otras fuentes "legales" suyas, no mueve ni un dedo. Así que dependemos de que "alguien" tenga nuestro mismo problema y de que además, lo reporte. No me parece una situación muy halagüeña :-(
Si alguien en la mailing list de sles o en los forums de Novell empieza a hacer "ruido" con un problema que tiene y no está reportado en bugzilla y van apareciendo más usuarios con ese mismo problema, Novell actuará de "oficio": arreglará el problema sin un bugzilla abierto, o inclusive lo abrirán ellos mismso si su protocolo interno se lo recomienda. Aquí estamos hablando de modelos Enterprise, aka negocio, aka $$$$. ¿Tu crees que si un usuario empieza a tener problemas de mal funcionamiento de ssh (y que esa situación solo se dá en SLES y no en otras distros) y lo dice en los foros o mailing list de SLES no va a haber un técnico de Novell al tanto del problema?? Créeme lo estará.
Pero yo no puedo depender de que otro usuario legalizado tenga mi mismo problema y de que haga el informe en bugzilla, eso no es serio...
Si es un bugzilla concreto para tu infraestructura, es normal que solo lo recibas tú. Con Red Hat pasa igual: si tu problema es solo tuyo te lo solucionan a tí y NO lo hacen público. ¿Cual es el problema??.
No hay que perder de vista que aquí se habla de una distro hecha por personas a las que les gusta SuSE, no por una empresa. Con openSuSE estás igual o peor ¿no?
No, con openSUSE si tengo un problema, reporto. Si es serio, seguramente me den a probar algún paquete prepado por ellos para que lo pruebe y les diga si el fallos se soluciona. Si es así, lo sacarán en la siguiente actualización.
Correcto, pero es que eso te lo va a hacer Novell gratis en referencia a openSLES, porque si es un problema en las SLES de rebote quedará arreglado en la openSLES. Sigo sin ver el problema.
Eso será si alguien informa de ese fallo. Pueden pasar años, meses o semanas... no sé a ti, pero personalmente no me gusta depender tanto de los demás >:-)
Además, los de Novell te podrían decir "O.k., mandamos un técnico a su oficina, para que puedan revisar el problema in-situ" ¿y qué hacemos, enviamos el bastidor a la casa del intermediario openSLESero, en Utah?
:-)
Mande?? ¿Alguien ha tenido un problema de tal magnitud que Novell le haya tenido que enviar un técnico, por ejemplo en España?? Yo llevo a muchos clientes (grandes y medianos) con Red Hat/CentOS en sus sistemas de test, pre-producción y producción y en ocasiones han surgido problemas muy serios y en ningún caso ha hecho falta que viniese un técnico de Red Hat al cliente.
Porque Novell "sabe" que tus clientes tienen contratos en regla, por eso no hacen preguntas de ese tipo >:-)
Pues igual pasará con el binomio openSLES/SLES.
No, porque en cuanto empiecen a indagar un poco sabrán que el bug no lo ha reportado quien tiene cuenta con ellos.
Repito: openSLES DEBE ser una distro hecha por personas a las que les gusta tener algo estable, robusto y con soporte largo. Y si la usas para sistemas de producción asumes ciertas cosas. Yo tendría más miedo de poner una openSuSE en producción que una openSLES y más de uno de vosotros tiene a openSuSE en producción ¿no?.
No, para nada ¿por qué? Si hay algún problema, puedo informar del fallo, sin temor a que Novell descubra nada ni tome cartas en el asunto. Si hay algún problema, puedo probar algún kernel o paquete que los desarrolladores me den "exprofeso", para mi problema, para que lo pruebe.
Pues igual pasa con CentOS. Y pasará con openSLES. En CentOS hay un repositorio de software expiremental que puedes probar cuanto quieras para ver si tu problema se soluciona. Si es así, el equipo de CentOS reporta a Red Hat y este lo soluciona. La cadena es la misma para openSLES. Sigo sin ver donde ves el problema....
El problema es que CentOS no tiene el mismo estatus ni la misma relación que tendría openSLES con Novell, no lo olvides.
Los problemas gordos (serios) en el bugzilla no van tan mal de tiempos... sólo he tenido un par de fallos "serios" (relacionados con el kernel) y se gestionaron en un tiempo prudencial (menos de 1 semana). Pues con openSLES igual, o mejor, porque el problema lo soluciona Novell. Tu solo tienes que "limpiar" el paquete, probarlo y liberar el parche.
¡Es será si Novell te lo quiere solucionar! >:-) Novell no es tan rápida sacando parches como openSUSE, ten en cuenta que paquete o parche que saque tiene que probarlo y certificarlo para todas las instalaciones.
Y Red Hat igual ¿o que esperabas? Y si hay un problema de verdad, a Novell no le queda otro remedio que solucionarlo ... O no te entiendo, o mejor ponme un ejemplo ...
Novell puede pasar olímpicamente de sacar un parche para un problema que lo reporta un usuario sin licencia.
Te recuerdo que la espera en openSUSE es de 8 meses (el tiempo que tardan en sacar una nueva versión con paquetes actualizados, más controladores, etc...), la de Novell es de ¿3 años entre versiones? >:-) Es decir, o lo tenemos bien "agarrado" el tema del contrato con Novell o nos pueden dejar k.o.
No me creo que un driver nuevo, Novell tarde 3 años en sacarlo si es un fabricante como LSI, Dell, HP, etc ... Ahora bien si el fabricante es "foo", entonces si ...
Ah, vaya, qué bonito... entonces también estamos atados a usar sólo hardware que esté certificado para SLES, pues vaya :-(
Entonces, ¿debemos entender que este tipo de "anuncios" no son más que una "herramienta de distracción" (aka: tomadura de pelo)? :-) [opensuse-project] More Support for the openSUSE Project http://lists.opensuse.org/opensuse-project/2009-08/msg00455.html
No, significa optimización de los recursos y mayor provecho de los mismos
¿Dices que "más soporte para openSUSE = menos soporte para las versiones"? ¿Y cómo se come eso? >:-?
¿Y yo he dicho eso?? Yo me refiero a la reducción del tiempo de mantenimiento entre las distintas releases de openSuSE ...
Y yo también me refiero a eso. A ver, nos están diciendo que van a destinar más recursos a openSUSE, pero al mismo tiempo, en paralelo, nos dicen que nos quitan 6 meses de soporte. Lo que digo que esas dos afirmaciones no son "coherentes" porque se contradicen mutuamente :-/. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 17:39 +0200, carlopmart escribió:
Camaleón wrote:
¿Y quién lo libera, CentOS o Rad Hat? Porque en el caso que nos atañe, Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor, no "a través" de alguien con contrato en vigor. CentOS solo libera si el error es suyo. Si no, CentOS no libera nada hasta que lo haga Red Hat. Y en 4 años usando CentOS eso solo ha ocurrido 2 veces: un error de la propia CentOS.
Pues eso te digo... si el error no es suyo (que es de Red Hat o que viene upstream) ¿qué hacemos? :-/
Esperar a que Novell lo solucione, igual que esperan los clientes de Red Hat a solucionarlo ...
Sobre "Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor", no me lo creo.
Jupe, pues ya me dirás... salvo que empiece a recibir el mismo informe de otras fuentes "legales" suyas, no mueve ni un dedo. Así que dependemos de que "alguien" tenga nuestro mismo problema y de que además, lo reporte. No me parece una situación muy halagüeña :-(
La fuente legal de la que hablas son los futuros desarrolladores de openSLES, que no olvides que tendrán subscripciones legales y ellos reportarán a Novell ... Así funciona en CentOS .... Creo que es un sistema sencillo, ¿no? Y sobretodo válido, tal vez no és rápido, pero si válido.
Si alguien en la mailing list de sles o en los forums de Novell empieza a hacer "ruido" con un problema que tiene y no está reportado en bugzilla y van apareciendo más usuarios con ese mismo problema, Novell actuará de "oficio": arreglará el problema sin un bugzilla abierto, o inclusive lo abrirán ellos mismso si su protocolo interno se lo recomienda. Aquí estamos hablando de modelos Enterprise, aka negocio, aka $$$$. ¿Tu crees que si un usuario empieza a tener problemas de mal funcionamiento de ssh (y que esa situación solo se dá en SLES y no en otras distros) y lo dice en los foros o mailing list de SLES no va a haber un técnico de Novell al tanto del problema?? Créeme lo estará.
Pero yo no puedo depender de que otro usuario legalizado tenga mi mismo problema y de que haga el informe en bugzilla, eso no es serio...
Pues entonces tu lo que pides es tener una SLES o RHEL legal .. Es la única forma de solucionar lo que pides ... Ojo!!: aviso a navegantes: que las Ubuntu LTS funcionan igual. Que nadie se lleve a equívocos. Si quieres que Canonical te solucione un problema concreto tuyo, te hará pagar por adelantado ... No harán ni caso si no tienes soporte. Espero que este punto esté claro.
Si es un bugzilla concreto para tu infraestructura, es normal que solo lo recibas tú. Con Red Hat pasa igual: si tu problema es solo tuyo te lo solucionan a tí y NO lo hacen público. ¿Cual es el problema??.
No hay que perder de vista que aquí se habla de una distro hecha por personas a las que les gusta SuSE, no por una empresa. Con openSuSE estás igual o peor ¿no?
No, con openSUSE si tengo un problema, reporto. Si es serio, seguramente me den a probar algún paquete prepado por ellos para que lo pruebe y les diga si el fallos se soluciona. Si es así, lo sacarán en la siguiente actualización. Correcto, pero es que eso te lo va a hacer Novell gratis en referencia a openSLES, porque si es un problema en las SLES de rebote quedará arreglado en la openSLES. Sigo sin ver el problema.
Eso será si alguien informa de ese fallo. Pueden pasar años, meses o semanas... no sé a ti, pero personalmente no me gusta depender tanto de los demás >:-)
Si es un error grave, créeme que queda solucionado en horas o días. Te pongo un ejemplo clarificador: upgrade entre distintas releases. Cuando upgradas una RHEL de versión, surgirá algún problema porque naturalmente no todos los entornos son iguales. Ventaja: CentOS o openSLES lo tendrán solucionado en su upgrade porque tardarán varias semanas en liberar la nueva versión y uno de los motivos de ese retraso es este.
Además, los de Novell te podrían decir "O.k., mandamos un técnico a su oficina, para que puedan revisar el problema in-situ" ¿y qué hacemos, enviamos el bastidor a la casa del intermediario openSLESero, en Utah?
:-)
Mande?? ¿Alguien ha tenido un problema de tal magnitud que Novell le haya tenido que enviar un técnico, por ejemplo en España?? Yo llevo a muchos clientes (grandes y medianos) con Red Hat/CentOS en sus sistemas de test, pre-producción y producción y en ocasiones han surgido problemas muy serios y en ningún caso ha hecho falta que viniese un técnico de Red Hat al cliente.
Porque Novell "sabe" que tus clientes tienen contratos en regla, por eso no hacen preguntas de ese tipo >:-) Pues igual pasará con el binomio openSLES/SLES.
No, porque en cuanto empiecen a indagar un poco sabrán que el bug no lo ha reportado quien tiene cuenta con ellos.
¿Como que no tiene cuenta con ellos? Llevo diciendo todo el rato que el futuro equipo de desarrollo de openSLES DEBE POSEER subscripciones legales a los canales SLES y poder abrir bugzillas si así es preciso. ¿Donde está la parte ilegal aquí???
Repito: openSLES DEBE ser una distro hecha por personas a las que les gusta tener algo estable, robusto y con soporte largo. Y si la usas para sistemas de producción asumes ciertas cosas. Yo tendría más miedo de poner una openSuSE en producción que una openSLES y más de uno de vosotros tiene a openSuSE en producción ¿no?.
No, para nada ¿por qué? Si hay algún problema, puedo informar del fallo, sin temor a que Novell descubra nada ni tome cartas en el asunto. Si hay algún problema, puedo probar algún kernel o paquete que los desarrolladores me den "exprofeso", para mi problema, para que lo pruebe. Pues igual pasa con CentOS. Y pasará con openSLES. En CentOS hay un repositorio de software expiremental que puedes probar cuanto quieras para ver si tu problema se soluciona. Si es así, el equipo de CentOS reporta a Red Hat y este lo soluciona. La cadena es la misma para openSLES. Sigo sin ver donde ves el problema....
El problema es que CentOS no tiene el mismo estatus ni la misma relación que tendría openSLES con Novell, no lo olvides.
Eso lo sospechamos, no lo sabemos a ciencia cierta. Yo estoy de acuerdo en eso contigo, pero cosas peores se han visto en este mundo ...
Los problemas gordos (serios) en el bugzilla no van tan mal de tiempos... sólo he tenido un par de fallos "serios" (relacionados con el kernel) y se gestionaron en un tiempo prudencial (menos de 1 semana). Pues con openSLES igual, o mejor, porque el problema lo soluciona Novell. Tu solo tienes que "limpiar" el paquete, probarlo y liberar el parche.
¡Es será si Novell te lo quiere solucionar! >:-) Novell no es tan rápida sacando parches como openSUSE, ten en cuenta que paquete o parche que saque tiene que probarlo y certificarlo para todas las instalaciones. Y Red Hat igual ¿o que esperabas? Y si hay un problema de verdad, a Novell no le queda otro remedio que solucionarlo ... O no te entiendo, o mejor ponme un ejemplo ...
Novell puede pasar olímpicamente de sacar un parche para un problema que lo reporta un usuario sin licencia.
Repito: el equipo de desarrollo de openSLES es una entidad LEGAL: tiene pagadas subscripciones...
Te recuerdo que la espera en openSUSE es de 8 meses (el tiempo que tardan en sacar una nueva versión con paquetes actualizados, más controladores, etc...), la de Novell es de ¿3 años entre versiones? >:-) Es decir, o lo tenemos bien "agarrado" el tema del contrato con Novell o nos pueden dejar k.o. No me creo que un driver nuevo, Novell tarde 3 años en sacarlo si es un fabricante como LSI, Dell, HP, etc ... Ahora bien si el fabricante es "foo", entonces si ...
Ah, vaya, qué bonito... entonces también estamos atados a usar sólo hardware que esté certificado para SLES, pues vaya :-(
Naturalmente. ¿Que fabricante de SO de este mundo no tiene su HCL??? Eso tampoco quiere decir que no intenten solucionar el problema, pero no están obligados a ello. ¿O es que crees que Microsoft te soporta todo el hardware del mercado para sus servidores Windows, o Apple, o VMWare, o Citrix??? No, todos tienen sus hcl.... Repito: hablamos de SO de linea Enterprise ...
Entonces, ¿debemos entender que este tipo de "anuncios" no son más que una "herramienta de distracción" (aka: tomadura de pelo)? :-) [opensuse-project] More Support for the openSUSE Project http://lists.opensuse.org/opensuse-project/2009-08/msg00455.html
No, significa optimización de los recursos y mayor provecho de los mismos
¿Dices que "más soporte para openSUSE = menos soporte para las versiones"? ¿Y cómo se come eso? >:-? ¿Y yo he dicho eso?? Yo me refiero a la reducción del tiempo de mantenimiento entre las distintas releases de openSuSE ...
Y yo también me refiero a eso.
A ver, nos están diciendo que van a destinar más recursos a openSUSE, pero al mismo tiempo, en paralelo, nos dicen que nos quitan 6 meses de soporte. Lo que digo que esas dos afirmaciones no son "coherentes" porque se contradicen mutuamente :-/.
Saludos,
Ok, a esto último. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 18:28 +0200, carlopmart escribió:
Camaleón wrote:
CentOS solo libera si el error es suyo. Si no, CentOS no libera nada hasta que lo haga Red Hat. Y en 4 años usando CentOS eso solo ha ocurrido 2 veces: un error de la propia CentOS.
Pues eso te digo... si el error no es suyo (que es de Red Hat o que viene upstream) ¿qué hacemos? :-/
Esperar a que Novell lo solucione, igual que esperan los clientes de Red Hat a solucionarlo ...
Serán los clientes de Red Hat y de Novell que tengan su licencia correspondiente.
Sobre "Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor", no me lo creo.
Jupe, pues ya me dirás... salvo que empiece a recibir el mismo informe de otras fuentes "legales" suyas, no mueve ni un dedo. Así que dependemos de que "alguien" tenga nuestro mismo problema y de que además, lo reporte. No me parece una situación muy halagüeña :-(
La fuente legal de la que hablas son los futuros desarrolladores de openSLES, que no olvides que tendrán subscripciones legales y ellos reportarán a Novell ...
Así funciona en CentOS .... Creo que es un sistema sencillo, ¿no? Y sobretodo válido, tal vez no és rápido, pero si válido.
Repito que CentOS no es que cuente con el beneplácito de Red Hat, pero no lo tienen en la diana. No hay trabas, los paquetes de parches están disponibles de forma abierta, algo que no pasa en Novell.
Pero yo no puedo depender de que otro usuario legalizado tenga mi mismo problema y de que haga el informe en bugzilla, eso no es serio...
Pues entonces tu lo que pides es tener una SLES o RHEL legal .. Es la única forma de solucionar lo que pides ...
No, yo sólo quiero el sistema de openSUSE como estaba, con 24 mesecitos de soporte y ya está O:-)
Ojo!!: aviso a navegantes: que las Ubuntu LTS funcionan igual. Que nadie se lleve a equívocos. Si quieres que Canonical te solucione un problema concreto tuyo, te hará pagar por adelantado ... No harán ni caso si no tienes soporte. Espero que este punto esté claro.
¿Ubuntu... pagar? ¿A quién? ¿En la LTS? ¿Por qué, hay contrato de por medio? Creo que no :-?
Correcto, pero es que eso te lo va a hacer Novell gratis en referencia a openSLES, porque si es un problema en las SLES de rebote quedará arreglado en la openSLES. Sigo sin ver el problema.
Eso será si alguien informa de ese fallo. Pueden pasar años, meses o semanas... no sé a ti, pero personalmente no me gusta depender tanto de los demás >:-)
Si es un error grave, créeme que queda solucionado en horas o días. Te pongo un ejemplo clarificador: upgrade entre distintas releases. Cuando upgradas una RHEL de versión, surgirá algún problema porque naturalmente no todos los entornos son iguales. Ventaja: CentOS o openSLES lo tendrán solucionado en su upgrade porque tardarán varias semanas en liberar la nueva versión y uno de los motivos de ese retraso es este.
Yo no "upgradeo" ni teniendo a todo el plantel de ingenieros de Novell a mi disposición para resolver los problemas :-P
Porque Novell "sabe" que tus clientes tienen contratos en regla, por eso no hacen preguntas de ese tipo >:-) Pues igual pasará con el binomio openSLES/SLES.
No, porque en cuanto empiecen a indagar un poco sabrán que el bug no lo ha reportado quien tiene cuenta con ellos.
¿Como que no tiene cuenta con ellos? Llevo diciendo todo el rato que el futuro equipo de desarrollo de openSLES DEBE POSEER subscripciones legales a los canales SLES y poder abrir bugzillas si así es preciso.
¿Donde está la parte ilegal aquí???
La parte (supuestamente) ilegal es que Novell sólo te da "soporte" si tienes contratada una licencia para tu equipo. Ojo, no digo que no puedas aplicar los parches por tu cuenta y riesgo, sino que no hay soporte, informes, reportes, bugzillas para un equipo sin licencia. Se supone que puedes distribuir los parches, pero hay queda todo. Si te pasa algo con esos paquetes, no hay quien te dé soporte (quien te atienda los bugzillas) "legalmente".
Pues igual pasa con CentOS. Y pasará con openSLES. En CentOS hay un repositorio de software expiremental que puedes probar cuanto quieras para ver si tu problema se soluciona. Si es así, el equipo de CentOS reporta a Red Hat y este lo soluciona. La cadena es la misma para openSLES. Sigo sin ver donde ves el problema....
El problema es que CentOS no tiene el mismo estatus ni la misma relación que tendría openSLES con Novell, no lo olvides.
Eso lo sospechamos, no lo sabemos a ciencia cierta. Yo estoy de acuerdo en eso contigo, pero cosas peores se han visto en este mundo ...
Con esos temas, en una empresa, no me gusta jugar. Necesitaría algún gesto claro y contundente por parte de Novell que indicara que no va a poner pegas a ese desarrollo, pero no creo que se dé :-(
Y Red Hat igual ¿o que esperabas? Y si hay un problema de verdad, a Novell no le queda otro remedio que solucionarlo ... O no te entiendo, o mejor ponme un ejemplo ...
Novell puede pasar olímpicamente de sacar un parche para un problema que lo reporta un usuario sin licencia.
Repito: el equipo de desarrollo de openSLES es una entidad LEGAL: tiene pagadas subscripciones...
Las suscripciones son para los equipos que se legalicen, no para el tuyo, el mío o el de cualquiera. ¿O crees que con pagar una licencia cubrimos a todos los equipos del mundo? :-)
No me creo que un driver nuevo, Novell tarde 3 años en sacarlo si es un fabricante como LSI, Dell, HP, etc ... Ahora bien si el fabricante es "foo", entonces si ...
Ah, vaya, qué bonito... entonces también estamos atados a usar sólo hardware que esté certificado para SLES, pues vaya :-(
Naturalmente. ¿Que fabricante de SO de este mundo no tiene su HCL??? Eso tampoco quiere decir que no intenten solucionar el problema, pero no están obligados a ello. ¿O es que crees que Microsoft te soporta todo el hardware del mercado para sus servidores Windows, o Apple, o VMWare, o Citrix??? No, todos tienen sus hcl.... Repito: hablamos de SO de linea Enterprise ...
No creo que en el bugzilla de openSUSE pongan traba alguna al hardware que tengas "sólo por su marca". Salvo que use controladores cerrados (caso de nvidia o ati) nunca he tenido problemas en ese aspecto >:-( Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 18:28 +0200, carlopmart escribió:
Camaleón wrote:
CentOS solo libera si el error es suyo. Si no, CentOS no libera nada hasta que lo haga Red Hat. Y en 4 años usando CentOS eso solo ha ocurrido 2 veces: un error de la propia CentOS.
Pues eso te digo... si el error no es suyo (que es de Red Hat o que viene upstream) ¿qué hacemos? :-/ Esperar a que Novell lo solucione, igual que esperan los clientes de Red Hat a solucionarlo ...
Serán los clientes de Red Hat y de Novell que tengan su licencia correspondiente.
Si, y los desarrolladores de openSLES SERAN clientes de Novell con "n" subscripciones, tanto como les den en donaciones y les alcance ...
Sobre "Novell no sacaría ese parche salvo que tenga la completa seguridad de que el error lo ha reportado alguien con contrato en vigor", no me lo creo.
Jupe, pues ya me dirás... salvo que empiece a recibir el mismo informe de otras fuentes "legales" suyas, no mueve ni un dedo. Así que dependemos de que "alguien" tenga nuestro mismo problema y de que además, lo reporte. No me parece una situación muy halagüeña :-(
La fuente legal de la que hablas son los futuros desarrolladores de openSLES, que no olvides que tendrán subscripciones legales y ellos reportarán a Novell ...
Así funciona en CentOS .... Creo que es un sistema sencillo, ¿no? Y sobretodo válido, tal vez no és rápido, pero si válido.
Repito que CentOS no es que cuente con el beneplácito de Red Hat
Sí cuenta con el beneplácito de Red Hat, hast cierto punto. De hecho se habla estos días, que ha habido algunos problemas en la gestión de CentOS, de donaciones por parte de Red Hat. Lo dije en un correo anterior: a Red Hat la existencia de CentOS le ha hecho subir el negocio ... Ojala hubiese algo así con openSLES y Novell ... , pero
no lo tienen en la diana. No hay trabas, los paquetes de parches están disponibles de forma abierta, algo que no pasa en Novell.
Correcto. Pero con una subscripcion si tienes acceso a esos fuentes ... que ojalá fuese como con Red Hat, pero es lo que da Novell ..
Pero yo no puedo depender de que otro usuario legalizado tenga mi mismo problema y de que haga el informe en bugzilla, eso no es serio... Pues entonces tu lo que pides es tener una SLES o RHEL legal .. Es la única forma de solucionar lo que pides ...
No, yo sólo quiero el sistema de openSUSE como estaba, con 24 mesecitos de soporte y ya está O:-)
Pues entonces dejemos el thread porque yo no estoy hablando de una openSuSE, yo siempre hablo de un clon de SLES ...
Ojo!!: aviso a navegantes: que las Ubuntu LTS funcionan igual. Que nadie se lleve a equívocos. Si quieres que Canonical te solucione un problema concreto tuyo, te hará pagar por adelantado ... No harán ni caso si no tienes soporte. Espero que este punto esté claro.
¿Ubuntu... pagar?
medio? Creo que no :-? Si, de soporte si quieres tenerlo. Tu me has puesto un ejemplo antes. Si compras una controladora que dá algún problema en una Ubuntu LTS y sabes que es un error de su kernel y precisas de una solución en pocos días o
Si ¿A quién? A Canoncial ¿En la LTS? Si ¿Por qué, hay contrato de por pagas o te esperas: o sea que igual que con RHEL, CentOS y demás ... Y ojo el tiempo de respuesta de Ubuntu es de alucine ...
Correcto, pero es que eso te lo va a hacer Novell gratis en referencia a openSLES, porque si es un problema en las SLES de rebote quedará arreglado en la openSLES. Sigo sin ver el problema.
Eso será si alguien informa de ese fallo. Pueden pasar años, meses o semanas... no sé a ti, pero personalmente no me gusta depender tanto de los demás >:-) Si es un error grave, créeme que queda solucionado en horas o días. Te pongo un ejemplo clarificador: upgrade entre distintas releases. Cuando upgradas una RHEL de versión, surgirá algún problema porque naturalmente no todos los entornos son iguales. Ventaja: CentOS o openSLES lo tendrán solucionado en su upgrade porque tardarán varias semanas en liberar la nueva versión y uno de los motivos de ese retraso es este.
Yo no "upgradeo" ni teniendo a todo el plantel de ingenieros de Novell a mi disposición para resolver los problemas :-P
¿Y si las circunstancias de producción te obligan???
Porque Novell "sabe" que tus clientes tienen contratos en regla, por eso no hacen preguntas de ese tipo >:-) Pues igual pasará con el binomio openSLES/SLES.
No, porque en cuanto empiecen a indagar un poco sabrán que el bug no lo ha reportado quien tiene cuenta con ellos. ¿Como que no tiene cuenta con ellos? Llevo diciendo todo el rato que el futuro equipo de desarrollo de openSLES DEBE POSEER subscripciones legales a los canales SLES y poder abrir bugzillas si así es preciso.
¿Donde está la parte ilegal aquí???
La parte (supuestamente) ilegal es que Novell sólo te da "soporte" si tienes contratada una licencia para tu equipo. Ojo, no digo que no puedas aplicar los parches por tu cuenta y riesgo, sino que no hay soporte, informes, reportes, bugzillas para un equipo sin licencia.
Se supone que puedes distribuir los parches, pero hay queda todo. Si te pasa algo con esos paquetes, no hay quien te dé soporte (quien te atienda los bugzillas) "legalmente".
Repito: que los desarrolladores de openSLES TENDRIAN subscripciones legales. Novell DEBE darles soporte por contrato ...
Pues igual pasa con CentOS. Y pasará con openSLES. En CentOS hay un repositorio de software expiremental que puedes probar cuanto quieras para ver si tu problema se soluciona. Si es así, el equipo de CentOS reporta a Red Hat y este lo soluciona. La cadena es la misma para openSLES. Sigo sin ver donde ves el problema....
El problema es que CentOS no tiene el mismo estatus ni la misma relación que tendría openSLES con Novell, no lo olvides. Eso lo sospechamos, no lo sabemos a ciencia cierta. Yo estoy de acuerdo en eso contigo, pero cosas peores se han visto en este mundo ...
Con esos temas, en una empresa, no me gusta jugar. Necesitaría algún gesto claro y contundente por parte de Novell que indicara que no va a poner pegas a ese desarrollo, pero no creo que se dé :-(
Y Red Hat igual ¿o que esperabas? Y si hay un problema de verdad, a Novell no le queda otro remedio que solucionarlo ... O no te entiendo, o mejor ponme un ejemplo ...
Novell puede pasar olímpicamente de sacar un parche para un problema que lo reporta un usuario sin licencia. Repito: el equipo de desarrollo de openSLES es una entidad LEGAL: tiene pagadas subscripciones...
Las suscripciones son para los equipos que se legalicen, no para el tuyo, el mío o el de cualquiera. ¿O crees que con pagar una licencia cubrimos a todos los equipos del mundo? :-)
No me has entendido. Si el equipo de desarrollo, con sus subscripciones legales, logra reproducir tu problema en sus entornos, ¿que les impide abrir un bugzilla???
No me creo que un driver nuevo, Novell tarde 3 años en sacarlo si es un fabricante como LSI, Dell, HP, etc ... Ahora bien si el fabricante es "foo", entonces si ...
Ah, vaya, qué bonito... entonces también estamos atados a usar sólo hardware que esté certificado para SLES, pues vaya :-( Naturalmente. ¿Que fabricante de SO de este mundo no tiene su HCL??? Eso tampoco quiere decir que no intenten solucionar el problema, pero no están obligados a ello. ¿O es que crees que Microsoft te soporta todo el hardware del mercado para sus servidores Windows, o Apple, o VMWare, o Citrix??? No, todos tienen sus hcl.... Repito: hablamos de SO de linea Enterprise ...
No creo que en el bugzilla de openSUSE pongan traba alguna al hardware que tengas "sólo por su marca". Salvo que use controladores cerrados (caso de nvidia o ati) nunca he tenido problemas en ese aspecto >:-(
Saludos,
Pero es que aquí yo estoy hablando de software de linea Enterprise ... No de distros "bleeding edge". ¿Tu crees por ejemplo que VMWare o IBM va a darte soporte si has comprado un hardware en casa de "Pepe Informaticos"? No, lo primero que te piden es un report del SO, y ahí canta todo el hardware que tienes ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 19:11 +0200, carlopmart escribió:
Camaleón wrote:
Pues eso te digo... si el error no es suyo (que es de Red Hat o que viene upstream) ¿qué hacemos? :-/
Esperar a que Novell lo solucione, igual que esperan los clientes de Red Hat a solucionarlo ...
Serán los clientes de Red Hat y de Novell que tengan su licencia correspondiente.
Si, y los desarrolladores de openSLES SERAN clientes de Novell con "n" subscripciones, tanto como les den en donaciones y les alcance ...
Pero eso no sirve. Con una sola suscripción debería servir para todos. No se puede ir adquiriendo suscripciones por cada usuario porque entonces no compensa, no tiene sentido :-(
La fuente legal de la que hablas son los futuros desarrolladores de openSLES, que no olvides que tendrán subscripciones legales y ellos reportarán a Novell ...
Así funciona en CentOS .... Creo que es un sistema sencillo, ¿no? Y sobretodo válido, tal vez no és rápido, pero si válido.
Repito que CentOS no es que cuente con el beneplácito de Red Hat
Sí cuenta con el beneplácito de Red Hat, hast cierto punto. De hecho se habla estos días, que ha habido algunos problemas en la gestión de CentOS, de donaciones por parte de Red Hat. Lo dije en un correo anterior: a Red Hat la existencia de CentOS le ha hecho subir el negocio ...
Ojala hubiese algo así con openSLES y Novell ...
Ya, eso sería lo ideal, pero Novell entiende que openSUSE es su banco de pruebas, tanto para SLED como para SLES.
no lo tienen en la diana. No hay trabas, los paquetes de parches están disponibles de forma abierta, algo que no pasa en Novell.
Correcto. Pero con una subscripcion si tienes acceso a esos fuentes ... que ojalá fuese como con Red Hat, pero es lo que da Novell ..
Sí, yo es lo encuentro muy limitado, digo, el modelo que ofrece Novell.
Pero yo no puedo depender de que otro usuario legalizado tenga mi mismo problema y de que haga el informe en bugzilla, eso no es serio...
Pues entonces tu lo que pides es tener una SLES o RHEL legal .. Es la única forma de solucionar lo que pides ...
No, yo sólo quiero el sistema de openSUSE como estaba, con 24 mesecitos de soporte y ya está O:-)
Pues entonces dejemos el thread porque yo no estoy hablando de una openSuSE, yo siempre hablo de un clon de SLES ...
Hombre, y yo también. Lo que te digo es que quiero tener las mismas opciones que tengo ahora con openSUSE, como mínimo, que es poder informar de fallos y el acceso a los parches sin tener que hacer triquiñuelas (pago una licencia, actualizo 500 servidores y aplico bugzillas para todos ellos :-P).
Ojo!!: aviso a navegantes: que las Ubuntu LTS funcionan igual. Que nadie se lleve a equívocos. Si quieres que Canonical te solucione un problema concreto tuyo, te hará pagar por adelantado ... No harán ni caso si no tienes soporte. Espero que este punto esté claro.
¿Ubuntu... pagar?
Si
¿A quién?
A Canoncial
¿En la LTS?
Si
¿Por qué, hay contrato de por
medio? Creo que no :-?
Si, de soporte si quieres tenerlo. Tu me has puesto un ejemplo antes. Si compras una controladora que dá algún problema en una Ubuntu LTS y sabes que es un error de su kernel y precisas de una solución en pocos días o pagas o te esperas: o sea que igual que con RHEL, CentOS y demás ... Y ojo el tiempo de respuesta de Ubuntu es de alucine ...
Ah, bueno, pero eso que dices es un paso "opcional" y me parece una forma estupenda de hacerlo porque NO impide el acceso a los parches a la gente que NO quiera ese soporte ni tampoco impide poner bugzillas. Ojalá Novell hiciera lo mismo: quien necesite soporte y certificación, a pasar por caja y a estar atado :-).
Si es un error grave, créeme que queda solucionado en horas o días. Te pongo un ejemplo clarificador: upgrade entre distintas releases. Cuando upgradas una RHEL de versión, surgirá algún problema porque naturalmente no todos los entornos son iguales. Ventaja: CentOS o openSLES lo tendrán solucionado en su upgrade porque tardarán varias semanas en liberar la nueva versión y uno de los motivos de ese retraso es este.
Yo no "upgradeo" ni teniendo a todo el plantel de ingenieros de Novell a mi disposición para resolver los problemas :-P
¿Y si las circunstancias de producción te obligan???
Digo que no actualizo sobre una versión existente, es decir, machacando la anterior. Yo instalo, siempre, en limpio, formateo incluido, manteniendo intacta la versión anterior.
¿Como que no tiene cuenta con ellos? Llevo diciendo todo el rato que el futuro equipo de desarrollo de openSLES DEBE POSEER subscripciones legales a los canales SLES y poder abrir bugzillas si así es preciso.
¿Donde está la parte ilegal aquí???
La parte (supuestamente) ilegal es que Novell sólo te da "soporte" si tienes contratada una licencia para tu equipo. Ojo, no digo que no puedas aplicar los parches por tu cuenta y riesgo, sino que no hay soporte, informes, reportes, bugzillas para un equipo sin licencia. Se supone que puedes distribuir los parches, pero hay queda todo. Si te pasa algo con esos paquetes, no hay quien te dé soporte (quien te atienda los bugzillas) "legalmente".
Repito: que los desarrolladores de openSLES TENDRIAN subscripciones legales. Novell DEBE darles soporte por contrato ...
Sí, pero eso sólo cubre "problemas en sus equipos" no en los tuyos, o los míos. Decir que el bug que se da en un equipo que no está licenciado, es "una triquiñuela". Ya me entiendes... vamos, que no sería "legal", legalmente hablando :-)
Repito: el equipo de desarrollo de openSLES es una entidad LEGAL: tiene pagadas subscripciones...
Las suscripciones son para los equipos que se legalicen, no para el tuyo, el mío o el de cualquiera. ¿O crees que con pagar una licencia cubrimos a todos los equipos del mundo? :-)
No me has entendido. Si el equipo de desarrollo, con sus subscripciones legales, logra reproducir tu problema en sus entornos, ¿que les impide abrir un bugzilla???
Pero es que el error (bug) NO se da en sus equipos, sino en el TUYO o en el mío que no tienen licencia (1 licencia = 1 equipo). Que tú tengas un bug en tu equipo NO significa que lo puedas reproducir en TODOS los equipos ¿entiendes? :-)
Naturalmente. ¿Que fabricante de SO de este mundo no tiene su HCL??? Eso tampoco quiere decir que no intenten solucionar el problema, pero no están obligados a ello. ¿O es que crees que Microsoft te soporta todo el hardware del mercado para sus servidores Windows, o Apple, o VMWare, o Citrix??? No, todos tienen sus hcl.... Repito: hablamos de SO de linea Enterprise ...
No creo que en el bugzilla de openSUSE pongan traba alguna al hardware que tengas "sólo por su marca". Salvo que use controladores cerrados (caso de nvidia o ati) nunca he tenido problemas en ese aspecto >:-(
Pero es que aquí yo estoy hablando de software de linea Enterprise ... No de distros "bleeding edge". ¿Tu crees por ejemplo que VMWare o IBM va a darte soporte si has comprado un hardware en casa de "Pepe Informaticos"? No, lo primero que te piden es un report del SO, y ahí canta todo el hardware que tienes ...
Pero en una openSLES NO necesitarías ese soporte porque NO te lo daría nadie sin tener una licencia de la SLES. Olvida una openSLES con soporte para hardware certificado, nadie te da soporte a un equipo sin una licencia certificada por Novell. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Pero eso no sirve. Con una sola suscripción debería servir para todos. No se puede ir adquiriendo suscripciones por cada usuario porque entonces no compensa, no tiene sentido :-(
No sirve con una sola descripción. Ejemplo: suite de alta disponibilidad para SLES - HAE. Aquí necesitas un mínimo de dos subscripciones, ¿no?. Yo no estoy hablando de llegar a múltiples subscripciones, pero a lo mejor con 5 bastan para así reproducir bugs.
Pues entonces dejemos el thread porque yo no estoy hablando de una openSuSE, yo siempre hablo de un clon de SLES ...
Hombre, y yo también.
Lo que te digo es que quiero tener las mismas opciones que tengo ahora con openSUSE, como mínimo, que es poder informar de fallos y el acceso a los parches sin tener que hacer triquiñuelas (pago una licencia, actualizo 500 servidores y aplico bugzillas para todos ellos :-P).
Ok, pues como dijiste en otro thread, y hasta donde llegan mis conocimientos, a día de hoy solo tienes una distro de propósito general que cubra esas necesidades: Debian. Una distro basada en línea enterprise solo te cubrirá parte de esas necesidades, pero por el contrario te ofrecerá soporte largo, robustez y disponibilidad ...
¿Y si las circunstancias de producción te obligan???
Digo que no actualizo sobre una versión existente, es decir, machacando la anterior. Yo instalo, siempre, en limpio, formateo incluido, manteniendo intacta la versión anterior.
como todos, pero ¿y si no puedes y debes hacerlo en la misma máquina???
Repito: que los desarrolladores de openSLES TENDRIAN subscripciones legales. Novell DEBE darles soporte por contrato ...
Sí, pero eso sólo cubre "problemas en sus equipos" no en los tuyos, o los míos. Decir que el bug que se da en un equipo que no está licenciado, es "una triquiñuela". Ya me entiendes... vamos, que no sería "legal", legalmente hablando :-)
Repito: el equipo de desarrollo de openSLES es una entidad LEGAL: tiene pagadas subscripciones...
Las suscripciones son para los equipos que se legalicen, no para el tuyo, el mío o el de cualquiera. ¿O crees que con pagar una licencia cubrimos a todos los equipos del mundo? :-) No me has entendido. Si el equipo de desarrollo, con sus subscripciones legales, logra reproducir tu problema en sus entornos, ¿que les impide abrir un bugzilla???
Pero es que el error (bug) NO se da en sus equipos, sino en el TUYO o en el mío que no tienen licencia (1 licencia = 1 equipo). Que tú tengas un bug en tu equipo NO significa que lo puedas reproducir en TODOS los equipos ¿entiendes? :-)
Claro que lo entiendo, pero ¿cuantas veces te ha pasado eso con hardware certificado que el propio fabricante de hard no te haya resuelto??? Y si el problema es a nivel de soft es muy probable que ya les esté pasando a otros y el equipo de desarrollo te pueda ayudar ...
Naturalmente. ¿Que fabricante de SO de este mundo no tiene su HCL??? Eso tampoco quiere decir que no intenten solucionar el problema, pero no están obligados a ello. ¿O es que crees que Microsoft te soporta todo el hardware del mercado para sus servidores Windows, o Apple, o VMWare, o Citrix??? No, todos tienen sus hcl.... Repito: hablamos de SO de linea Enterprise ...
No creo que en el bugzilla de openSUSE pongan traba alguna al hardware que tengas "sólo por su marca". Salvo que use controladores cerrados (caso de nvidia o ati) nunca he tenido problemas en ese aspecto >:-(
Pero es que aquí yo estoy hablando de software de linea Enterprise ... No de distros "bleeding edge". ¿Tu crees por ejemplo que VMWare o IBM va a darte soporte si has comprado un hardware en casa de "Pepe Informaticos"? No, lo primero que te piden es un report del SO, y ahí canta todo el hardware que tienes ...
Pero en una openSLES NO necesitarías ese soporte porque NO te lo daría nadie sin tener una licencia de la SLES. Olvida una openSLES con soporte para hardware certificado, nadie te da soporte a un equipo sin una licencia certificada por Novell.
Saludos,
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-08-26 a las 20:29 +0200, carlopmart escribió:
Pero eso no sirve. Con una sola suscripción debería servir para todos. No se puede ir adquiriendo suscripciones por cada usuario porque entonces no compensa, no tiene sentido :-(
No sirve con una sola descripción. Ejemplo: suite de alta disponibilidad para SLES - HAE. Aquí necesitas un mínimo de dos subscripciones, ¿no?. Yo no estoy hablando de llegar a múltiples subscripciones, pero a lo mejor con 5 bastan para así reproducir bugs.
Vale, pero lo que quiero que se entienda es que esas suscripciones se circunscriben a los equipos sobre los que se pide la licencia. El EULA de Novell permite la distribución de los paquetes, parches y Service Packs (siempre que sean paquetes GPL y eliminado la marca, etc...) para quien tenga acceso a ellos (por ejemplo, quien haya comprado una licencia) pero lo que NO admite es dar servicio de soporte a equipos que no tengan licencia vigente. Tenemos los paquetes y los parches (legalmente) pero no el soporte. Sí, bueno, tenerlo lo tenemos, pero no "legalmente". Eso era lo que quería que se entendiera :-)
Lo que te digo es que quiero tener las mismas opciones que tengo ahora con openSUSE, como mínimo, que es poder informar de fallos y el acceso a los parches sin tener que hacer triquiñuelas (pago una licencia, actualizo 500 servidores y aplico bugzillas para todos ellos :-P).
Ok, pues como dijiste en otro thread, y hasta donde llegan mis conocimientos, a día de hoy solo tienes una distro de propósito general que cubra esas necesidades: Debian. Una distro basada en línea enterprise solo te cubrirá parte de esas necesidades, pero por el contrario te ofrecerá soporte largo, robustez y disponibilidad ...
Cierto.
Digo que no actualizo sobre una versión existente, es decir, machacando la anterior. Yo instalo, siempre, en limpio, formateo incluido, manteniendo intacta la versión anterior.
como todos, pero ¿y si no puedes y debes hacerlo en la misma máquina???
Claro, yo me refiero a instalar desde cero "en la misma máquina". ¿Dices si no tengo espacio en disco para llevar a cabo una instalación en paralelo? Hombre, pues tendría que hacerlo a las bravas (machacando la versión en producción), pero sería la última de las opciones que consideraría y antes de hacerlo tomaría precauciones haciendo una copia-clon del sistema actual con clonezilla, que va de lujo O:-)
Pero es que el error (bug) NO se da en sus equipos, sino en el TUYO o en el mío que no tienen licencia (1 licencia = 1 equipo). Que tú tengas un bug en tu equipo NO significa que lo puedas reproducir en TODOS los equipos ¿entiendes? :-)
Claro que lo entiendo, pero ¿cuantas veces te ha pasado eso con hardware certificado que el propio fabricante de hard no te haya resuelto???
Pero olvida eso del hardware certificado, en una openSLES no existiría ese concepto. Nadie te va a dar soporte. Si te valen los parches que el fabricante haya podido sacar para la SLES, bien, pero si no, pues no hay nada que hacer.
Y si el problema es a nivel de soft es muy probable que ya les esté pasando a otros y el equipo de desarrollo te pueda ayudar ...
Sí, eso sí, pero sigue siendo arriesgado. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El 2009-08-26 a las 20:29 +0200, carlopmart escribió:
Pero eso no sirve. Con una sola suscripción debería servir para todos. No se puede ir adquiriendo suscripciones por cada usuario porque entonces no compensa, no tiene sentido :-( No sirve con una sola descripción. Ejemplo: suite de alta disponibilidad para SLES - HAE. Aquí necesitas un mínimo de dos subscripciones, ¿no?. Yo no estoy hablando de llegar a múltiples subscripciones, pero a lo mejor con 5 bastan para así reproducir bugs.
Vale, pero lo que quiero que se entienda es que esas suscripciones se circunscriben a los equipos sobre los que se pide la licencia.
El EULA de Novell permite la distribución de los paquetes, parches y Service Packs (siempre que sean paquetes GPL y eliminado la marca, etc...) para quien tenga acceso a ellos (por ejemplo, quien haya comprado una licencia) pero lo que NO admite es dar servicio de soporte a equipos que no tengan licencia vigente.
Tenemos los paquetes y los parches (legalmente) pero no el soporte. Sí, bueno, tenerlo lo tenemos, pero no "legalmente". Eso era lo que quería que se entendiera :-)
Se entiende. Pero piensa esto: CentOS está en la misma posición que indicas respecto a Red Hat y está en múltiples entornos de producción.
Lo que te digo es que quiero tener las mismas opciones que tengo ahora con openSUSE, como mínimo, que es poder informar de fallos y el acceso a los parches sin tener que hacer triquiñuelas (pago una licencia, actualizo 500 servidores y aplico bugzillas para todos ellos :-P). Ok, pues como dijiste en otro thread, y hasta donde llegan mis conocimientos, a día de hoy solo tienes una distro de propósito general que cubra esas necesidades: Debian. Una distro basada en línea enterprise solo te cubrirá parte de esas necesidades, pero por el contrario te ofrecerá soporte largo, robustez y disponibilidad ...
Cierto.
Digo que no actualizo sobre una versión existente, es decir, machacando la anterior. Yo instalo, siempre, en limpio, formateo incluido, manteniendo intacta la versión anterior. como todos, pero ¿y si no puedes y debes hacerlo en la misma máquina???
Claro, yo me refiero a instalar desde cero "en la misma máquina". ¿Dices si no tengo espacio en disco para llevar a cabo una instalación en paralelo? Hombre, pues tendría que hacerlo a las bravas (machacando la versión en producción), pero sería la última de las opciones que consideraría y antes de hacerlo tomaría precauciones haciendo una copia-clon del sistema actual con clonezilla, que va de lujo O:-)
Ok a todo, pero una ventaja brutal que te ofrece un Enterprise es que SÍ puedes hacer este tipo de upgrade. Yo lo he hecho (haciendo mis bakcups, provando antes en maquinas virtuales, etc, pero sin llegar a usar un clonezilla) y siempre me ha funcionado. ojo porque digo "siempre me ha funcionado", o sea los entornos que yo controlo al 100%, porque sé donde se van a producir los errores de upgrade.
Pero es que el error (bug) NO se da en sus equipos, sino en el TUYO o en el mío que no tienen licencia (1 licencia = 1 equipo). Que tú tengas un bug en tu equipo NO significa que lo puedas reproducir en TODOS los equipos ¿entiendes? :-) Claro que lo entiendo, pero ¿cuantas veces te ha pasado eso con hardware certificado que el propio fabricante de hard no te haya resuelto???
Pero olvida eso del hardware certificado, en una openSLES no existiría ese concepto.
Puntualización: openSLES estaría "certificada encubiertamente" bajo el mismo hard que lo está la SLES. Por lo tanto si tienes problemas con un Dell SC1450, por ejemplo, con SLES deberías tenerlos con openSLES y a la inversa también. Esto ocurre en el 99,9999% de los casos con el binomio CentOS/RedHat, Nadie te va a dar soporte. Si te valen los parches que
el fabricante haya podido sacar para la SLES, bien, pero si no, pues no hay nada que hacer.
O sí. Siempre se puede hacer algo. En todos los años que llevo en esto, nunca me he encontrado con un problema así que no se pueda resolver....
Y si el problema es a nivel de soft es muy probable que ya les esté pasando a otros y el equipo de desarrollo te pueda ayudar ...
Sí, eso sí, pero sigue siendo arriesgado.
Saludos,
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
carlopmart escribió:
Camaleón wrote:
El 2009-08-26 a las 20:29 +0200, carlopmart escribió:
Pero eso no sirve. Con una sola suscripción debería servir para todos. No se puede ir adquiriendo suscripciones por cada usuario porque entonces no compensa, no tiene sentido :-( No sirve con una sola descripción. Ejemplo: suite de alta disponibilidad para SLES - HAE. Aquí necesitas un mínimo de dos subscripciones, ¿no?. Yo no estoy hablando de llegar a múltiples subscripciones, pero a lo mejor con 5 bastan para así reproducir bugs.
Vale, pero lo que quiero que se entienda es que esas suscripciones se circunscriben a los equipos sobre los que se pide la licencia. El EULA de Novell permite la distribución de los paquetes, parches y Service Packs (siempre que sean paquetes GPL y eliminado la marca, etc...) para quien tenga acceso a ellos (por ejemplo, quien haya comprado una licencia) pero lo que NO admite es dar servicio de soporte a equipos que no tengan licencia vigente. Tenemos los paquetes y los parches (legalmente) pero no el soporte. Sí, bueno, tenerlo lo tenemos, pero no "legalmente". Eso era lo que quería que se entendiera :-)
Se entiende. Pero piensa esto: CentOS está en la misma posición que indicas respecto a Red Hat y está en múltiples entornos de producción.
Lo que te digo es que quiero tener las mismas opciones que tengo ahora con openSUSE, como mínimo, que es poder informar de fallos y el acceso a los parches sin tener que hacer triquiñuelas (pago una licencia, actualizo 500 servidores y aplico bugzillas para todos ellos :-P). Ok, pues como dijiste en otro thread, y hasta donde llegan mis conocimientos, a día de hoy solo tienes una distro de propósito general que cubra esas necesidades: Debian. Una distro basada en línea enterprise solo te cubrirá parte de esas necesidades, pero por el contrario te ofrecerá soporte largo, robustez y disponibilidad ...
Cierto.
Digo que no actualizo sobre una versión existente, es decir, machacando la anterior. Yo instalo, siempre, en limpio, formateo incluido, manteniendo intacta la versión anterior. como todos, pero ¿y si no puedes y debes hacerlo en la misma máquina???
Claro, yo me refiero a instalar desde cero "en la misma máquina". ¿Dices si no tengo espacio en disco para llevar a cabo una instalación en paralelo? Hombre, pues tendría que hacerlo a las bravas (machacando la versión en producción), pero sería la última de las opciones que consideraría y antes de hacerlo tomaría precauciones haciendo una copia-clon del sistema actual con clonezilla, que va de lujo O:-)
Ok a todo, pero una ventaja brutal que te ofrece un Enterprise es que SÍ puedes hacer este tipo de upgrade. Yo lo he hecho (haciendo mis bakcups, provando antes en maquinas virtuales, etc, pero sin llegar a usar un clonezilla) y siempre me ha funcionado. ojo porque digo "siempre me ha funcionado", o sea los entornos que yo controlo al 100%, porque sé donde se van a producir los errores de upgrade.
Pero es que el error (bug) NO se da en sus equipos, sino en el TUYO o en el mío que no tienen licencia (1 licencia = 1 equipo). Que tú tengas un bug en tu equipo NO significa que lo puedas reproducir en TODOS los equipos ¿entiendes? :-) Claro que lo entiendo, pero ¿cuantas veces te ha pasado eso con hardware certificado que el propio fabricante de hard no te haya resuelto???
Pero olvida eso del hardware certificado, en una openSLES no existiría ese concepto.
Puntualización: openSLES estaría "certificada encubiertamente" bajo el mismo hard que lo está la SLES. Por lo tanto si tienes problemas con un Dell SC1450, por ejemplo, con SLES deberías tenerlos con openSLES y a la inversa también. Esto ocurre en el 99,9999% de los casos con el binomio CentOS/RedHat,
Nadie te va a dar soporte. Si te valen los parches que
el fabricante haya podido sacar para la SLES, bien, pero si no, pues no hay nada que hacer.
O sí. Siempre se puede hacer algo. En todos los años que llevo en esto, nunca me he encontrado con un problema así que no se pueda resolver....
O sí, dependiendo del cliente, por la cuenta que les trae... Dile a OKI, que llamas del centro computacional "la madre de las madres" de la Junta de Extremadura, que las impresoras que se han comprado para el Dpto de Sanidad están dando problemas con Linex... verás si lo arreglan, porque si no al año que viene le compran las impresoras a otros. Claro, que para eso tienes que decir, mira tío, a mí no me hagas perder el tiempo, yo te compro 5000 impresoras todos los años... o me lo arreglas a la de ya, o al año que viene le compra impresoras a OKI tu abuela.
Y si el problema es a nivel de soft es muy probable que ya les esté pasando a otros y el equipo de desarrollo te pueda ayudar ...
Sí, eso sí, pero sigue siendo arriesgado.
Saludos,
-- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
carlopmart escribió:
Pero eso no sirve. Con una sola suscripción debería servir para todos. No se puede ir adquiriendo suscripciones por cada usuario porque entonces no compensa, no tiene sentido :-(
No sirve con una sola descripción. Ejemplo: suite de alta disponibilidad para SLES - HAE. Aquí necesitas un mínimo de dos subscripciones, ¿no?. Yo no estoy hablando de llegar a múltiples subscripciones, pero a lo mejor con 5 bastan para así reproducir bugs.
Pues entonces dejemos el thread porque yo no estoy hablando de una openSuSE, yo siempre hablo de un clon de SLES ...
Hombre, y yo también.
Lo que te digo es que quiero tener las mismas opciones que tengo ahora con openSUSE, como mínimo, que es poder informar de fallos y el acceso a los parches sin tener que hacer triquiñuelas (pago una licencia, actualizo 500 servidores y aplico bugzillas para todos ellos :-P).
Ok, pues como dijiste en otro thread, y hasta donde llegan mis conocimientos, a día de hoy solo tienes una distro de propósito general que cubra esas necesidades: Debian. Una distro basada en línea enterprise solo te cubrirá parte de esas necesidades, pero por el contrario te ofrecerá soporte largo, robustez y disponibilidad ...
¿Estás seguro de eso?
-- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
csalinux wrote:
carlopmart escribió:
Pero eso no sirve. Con una sola suscripción debería servir para todos. No se puede ir adquiriendo suscripciones por cada usuario porque entonces no compensa, no tiene sentido :-( No sirve con una sola descripción. Ejemplo: suite de alta disponibilidad para SLES - HAE. Aquí necesitas un mínimo de dos subscripciones, ¿no?. Yo no estoy hablando de llegar a múltiples subscripciones, pero a lo mejor con 5 bastan para así reproducir bugs.
Pues entonces dejemos el thread porque yo no estoy hablando de una openSuSE, yo siempre hablo de un clon de SLES ... Hombre, y yo también.
Lo que te digo es que quiero tener las mismas opciones que tengo ahora con openSUSE, como mínimo, que es poder informar de fallos y el acceso a los parches sin tener que hacer triquiñuelas (pago una licencia, actualizo 500 servidores y aplico bugzillas para todos ellos :-P). Ok, pues como dijiste en otro thread, y hasta donde llegan mis conocimientos, a día de hoy solo tienes una distro de propósito general que cubra esas necesidades: Debian. Una distro basada en línea enterprise solo te cubrirá parte de esas necesidades, pero por el contrario te ofrecerá soporte largo, robustez y disponibilidad ...
¿Estás seguro de eso?
Humm, ¿a que te refieres?? ¿A lo que digo de Debian?? Ya digo que "hasta donde yo sé" ... No tengo controladas todas las distros :)) -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Miércoles, 26 de Agosto de 2009 13:36:46 Armin Díaz Argaña escribió:
Yo lo veo mucho mas sencillo.
Apuntar a una openSLES, tener una suscripción a novell y ...
Bien, acabas de inventar la rueda triangular (yo antes había inventado la cuadrada, ¿o quizás es al revés?) Sin embargo, la _única_ rueda que puede funcionar, _¡¡¡ es la redonda !!!_, que nos sólo ya existe, sino que además es gratuita (y libre, por cierto). Estamos dándole vueltas para hacer que nuestra openSUSE de toda la vida (aka SuSE) se parezca a otras LTS que _ya existen_ ¿acaso no nos damos cuenta de que es muchiiiiiisimo más fácil que nosostros, los simples usuarios, cambiemos de distribución que poner en marcha un proyecto faraónico, a sabiendas de que no tenemos recursos para mantenerlo? Por favor, seamos sensatos y analicemos los siguientes puntos de vista: a) si yo puedo mantener mi sistema actualizado ¿para que necesito que los de la distribución XX o YY me suministren actualizaciones? b) si no puedo hacerlo, ¿porqué he de pensar que la solución es montar un proyecto que no soy capaz de mantener? Saludos. Miquel. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (6)
-
Armin Díaz Argaña -
Camaleón -
carlopmart -
csalinux -
Miquel A. Noguera -
Rafa Griman