Mailinglist Archive: opensuse-es (1319 mails)

[Armin Díaz Argaña <armindiaz@xxxxxxxxx>]

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<carlopmart@xxxxxxxxx> escribió:
> 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@xxxxxxxxxxxx
> Para obtener el resto de direcciones-comando, mande
> un mensaje a:
>  opensuse-es+help@xxxxxxxxxxxx
--
Para dar de baja la suscripción, mande un mensaje a:
   opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
   opensuse-es+help@xxxxxxxxxxxx