La actualización a QT 4.7.2 nos traerá más de un dolor de cabeza

Velneo
1

Pues como reza el título de este post, la actualización a 4.7.2 de v7.7 nos va a traer más de un dolro de cabeza, y dos, como se está viendo por los foros.

Yo llevo desde el Martes (en la actualización) sin poder trabajar. En casa dispongo de OpenSuse 11.4, que trae QT 4.7.1, y a Velneo, no le gusta esa versión de QT, por lo que me dá el error
.

Cannot mix incompatible Qt library (0x40701) with this library (0x40702)

Puesto en OpenSuse tenía problemas para conseguir instalar 4.7.2, he probado en una máquina Virtual, instalar otro Linux (PCLinuxOS, que trabaja con KDE, y tenía ganas de probarla) que de serie sí trae Qt actualizado, glibc 2.12, QT 4.7.3, vamos..perfecta...pero entonces, me dá el error:

Cannot mix incompatible Qt library (0x40703) with this library (0x40702)

Aparentemente, Velneo quiere que tenga esa versión en específico, pero ésto no debería ser así, ya que tendría que buscar específicamente una distribución de Linux que trabaje con esa versión, y además, y más importante, que no se actualice, porque si se actualizara, Velneo dejará de funcionar.

No sé si existe alguna solución alternativa.

Este es el mensaje que he reportado a Soporte, pero modificado para que el mensaje cuadre colocado aquí en el foro

Y no comentado a Soporte. Esto, puede afectar gravemente en los deploys, si tenemos clientes con distintas distribuciones de LInux, no podemos ir a cambiarle su sistema con todo montado, y todo esto, sin contar con los problemas que se están leyendo, de servidores que se encuentran en producción, y no podemos cambiar ciertas librerías.

En fin...esperemos que exista una solución rápida.

2

Nuestra experiencia respecto a Qt en esta nueva version es positiva, mas velocidad y menos peso en ejecucion respecto a proceso cpu.

Creo que la decision de actualizar Qt continuamente para Velneo es acertada. Otra cuestion distinta es como el departamento de desarrollo y nuestros clientes tienen que adoptar las versiones de nuestros productos.

Nosotros hemos desarrollado con v7.3 mucho tiempo y hasta la v7.6/7.7 no hemos cambiado de version. Alguno creera que es una mala politica, pero de esta forma evitamos sustos.

Atentamente,
Jorge Hontoria
http://tipesoft.com

3

Nosotros hemos desarrollado con v7.3 mucho tiempo y hasta la v7.6/7.7 no hemos cambiado de version. Alguno creera que es una mala politica, pero de esta forma evitamos sustos.

Y en mi opinión, es una buena política, siempre y cuando la herramienta esté "terminada", cosa que hasta esta versión, no ha salido, llamémosle, de versión Beta (lease impresoras lógicas, decimales, tabulación y un largo etcétera). Ninguna herramienta debe hacer cambios bruscos de versión en una iteración "menor", y mucho menos romper compatibilidad de esta manera. Aunque las comparaciones sean odiosas, pero otra-herramienta-que-no-nombrare, en su última versión, teniendo lo último de lo último, mantiene compatibilidad con Win98...

Si instalas "tu aplicación" en una máquina que tenga qt4.7.2, y ésta, debida a actualizaciones, pasa a ser qt4.7.3, tu aplicación dejará de funcionar. Ahora vas, y le dices a tu cliente que tienes que (o que se busque la vida) reinstalarlo todo, para que la aplicación que te ha pagado, vuelva a funcionar. No funciona, ni con versiones anteriores de QT (algo que medio se podría aceptar), pero es que posteriores tampoco, 4.7.2 y se acabó. Una cosa son nuestros equipos de desarrollo, y otros los entornos de producción, que como bien sabrás, nunca tienen lo último por cuestiones de estabilidad.

Imagina hace 4 años, por ejemplo, que v7.7 rompiera compatibilidad con WinXP y Windows 2003 server, y que la actualización de esas aplicaciones en producción, deben ser "forzosas" debido, a "funcionalidades" que trae la nueva versión o arreglos de bugs. Le dices a tu cliente que debe migrar su servidor de 2003 a 2008 y los puestos cliente a Win 7 (contando que el hardware y drivers lo aguante). ¿Quien acarrea con esos costos de licencias y horas de migración? A mi, me ha dejado sin poder trabajar. Nadie me avisó de problemas de compatibilidad antes de reiniciar mi vServer. Bueno, sí, con las nuevas librerías, pero no que tenían que ser exactamente esas, ni más, ni menos.

El problema es mucho más grave de lo que parece a simple vista, no hablamos de ninguna tontería.

Puedo estar equivocado, y la solución sea mucho más simple de lo que parece y yo esté largando de más, pero como sea realmente así, que deba funcionar con 4.7.2, ni inferior, ni superior, es un fallo muy muy gordo.

En fin, antes de ponerme tan tan catastrófico, esperaré la respuesta de soporte, y confío que lo solucionen en v7.7.1 (y ya me las arreglaré para poder trabajar) pero la cosa pinta fea.

4

Pues concuerdo contigo Giuseppe, actualmente no tengo nada en producción con V7, peeeeeero se me erizan los pelos de solo pensar el lio que se arma en este caso.

De alguna forma se debe garantizar la compatibilidad hacia atras de todas las versiones, si no es así, ¿de que me serviría entonces adquirir licencias vEnterprise? las cuales mientras estes suscrito tienes derecho a todas las actualizaciones de vservers V7, y el resto de los componentes, si para poder actualizar a mis clientes tendré que hacer un verdadero circo y obligarlos a que si quieren mejoras en rendimiento, estabilidad y lo que salga, tendrán que gastar en la posible actualización.

Me gusta velneo por su facilidad y rentabilidad, pero este tipo de situaciones van al traste y se convierten para las empresas en pérdida de dinero, porqué?, porque un argumento de venta de las vEnterprise es precisamente ese, el derecho a todas las actualizaciones que salgan mientras dure el contrato, en teoría sin cobrarles un centavo más, ¿quien carga con esos gastos? pues en principio el cliente te dirá que tú, que ya le cobraste y ahora se lo haces gratis. la otra opción es quedarse callado y no informar a los clientes que hay nuevas versiones de los componentes utilizados en la solución que ya le vendí, situación que no me parece para nada ética.

Si los cambios o mejoras en un vServer no son críticas, puedo mantener la versión que ya esta instalada, pero si lo que se soluciona con una nueva versión, es algo crítico (pérdidas accidentales de datos, causadas por algún mal funcionamiento del vServer) pues la actualización se vuelve crítica, pero si a esto le agrego que le tengo que cambiar o actualizar todo el ambiente y todos sus clientes, etc. pues voy a tener una gran fuga de efectivo.

Como bien dices, o al menos así lo entiendo, compatibilidad hacia atras y una versión 7.7.1 a la brevedad.

Podríamos discutir "n" cantidad de situaciones, de paliativos, de cosas y nunca terminar, pero ni tengo tiempo ni ganas, la única realidad que en estos momentos veo es que se integre dicha compatibilidad sin que se afecte a los sistemas que ya estan en producción y obviamente el bolsillo de las empresas que han confiado en la plataforma.

Saludos.

5

Sé que habrá muchos foreros que no están de acuerdo , pero insisto, la culpa de que este tipo de cosas sucedan es por emplear un software que estaba en BETA, incluso en esta versión ya se ha visto que trae errores que han obligado incluso a participar en el foro a Juan Muñoz, cosa que por cierto es de agradecer, en foros de este tipo se ven pocas cosas así, en fin, si tu estás viendo que el software está de aquella manera y lo utilizas en producción, pues no echemos la culpa a Velneo, tu cliente no lo va a hacer para el tú eres el responsable.

Para que no haya malos entendidos diré que a mí me gusta la herramienta tanto como al que más y deseo que cumpla todas nuestras expectativas, dentro de un límite claro está, pero mi opinión es que le falta un año más para estar lista.

6

Independientemente que sonovision tenga o no razón :D actualizo.

Velneo incluye las librerías necesarias, y en su versión necesaria, para enlazarlas de manera estática, por ello se arranca desde el script, para que las coja de ahí.

Mi pequeña teoría, (sin poder probar ya que no estoy en la máquina donde falla), es, y es sólo una suposición ya que no estoy muy puesto, que éstas deberían añadirse a QTDIR, y no al path, y supongo, que tiene que existir algún tipo de incompatibilidad entre 4.7.2 con las demás versiones, que al encontrarse juntitas en el path, pues peta.

Resumiendo, al menos, tengo una respuesta algo esperanzadora, lo que hay que localizar es el error concreto de por qué no se está tirando de las librerías en la ruta correcta. Espero que se localice una solución para mañana máximo, si no, seguiré el fin de semana sin poder trabajar :S

Así que, a falta de una solución final, he de retractarme de ciertas cosas que he dicho por el calentón (aunque, no fuera de razón si de verdad hubiera sido así), y pido disculpas por el ruido. Entre no poder trabajar, y el post de vServer.sh, pillé un acojone y mosqueo considerable.

Seguiré actualizando, y gracias públicamente a Soporte por su pronta contestación. A ver si sacara tiempo libre (y me funcionara Velneo ;) ) para terminar vCervezas y poneros una ;)

7

@Giuseppe

Estoy perfectamente de acordo contigo Giuseppe.
En mi caso además de todo lo trabajo que hay que tener para configurar un nuevo servidor, con sus webs, dns, emails, antivirus, anti-spam, optimizadores de php y un largo etc, tengo que tirar a la basura el diñero de un año de subscrición de un servidor dedicado, no es mucho, pero son cerca de 1000€.

Lo que me preocupa es que incluso la versión (no beta) más actualizada de Centos no suporta aún estas librerias que usa velneo 7.7, o sea que también tengo que cambiar de sistema operativo, con todas las diferencias de comandos y configuraciones que puedan existir.

Es por este tipo de cosas, que por vezes, me questiono si no valle más programar en c++ puro y duro.

8

No sé como haceis las instalaciones de vServers, pero en nuestros servidores en la nube soportamos simultaneamente cualquier versión de Velneo desde la v7.3 mediante las librerias en modo estático.

Tenemos ubuntu 10.10 y el resultado es satisfactorio.

Atentamente,
Jorge Hontoria
http://tipesoft.com

9

Hola jorge,

No entiendo muy bien lo que comentas, perdona mi ignorancia. Nuestro problema parece ser que es que la ver 7.7 necesita glibc >=2.11, esto lo traen las distros mas conocidas fc12 en adelante, ubuntu 10.10 en adelante. Pero no lo traen la mayoría de distros de hosting de Internet, que en gran medida están con centos o redhat.
Desconozco de momento la manera de instalar glibc >= 2.5 a centos o si pueden convivir ambas.

Un saludo
Manolo

10

El problema, como bien apuntas, tiene que ver con que utilizais distros con versiones glibc < 2.11. Los proveedores de hosting tradicionales es lo que tienen que son poco flexibles para estas cuestiones (son adecuados para otras). Tendreis que buscar un buen proveedor cloud bien en España o fuera. Ya sabemos que son algo más caros que los proveedores de hosting pero para estos servicios es mejor tener un mayor control de la plataforma.

Si deseais asesoramiento podeis poneros en contacto con nosotros mediante http://tipesoft.com/contacto

Atentamente,
Jorge Hontoria
http://tipesoft.com

11

@jorge.hontoria

Y tú dale que erre que erre. El entorno que yo estoy hablando, es en OVH, con un VPS con CentOS 5.6 (el sistema que la mayoría de proveedores ofrecen). Si puedo instalarle Debian 6 (que es lo que tendré que hacer este finde, y nadie me lo va a pagar) y lo que yo quiera, pero de nuevo, volvemos a la película que hay que montar, no defiendas lo indefendible por favor.

@Todos

El problema se ha solucionado. Las QT chocan con la versión de las QT instaladas. Solución? de momento, mover las librerías QT de la carpeta Velneo a una subcarpeta libs, por ejemplo, para que estén fuera del path, y Velneo use las instaladas en el sistema. Eso si, de momento, Velneo no está testado con qt.4.7.3, y en cuanto vea las rutas que hay que modificar para que use solo sus librerías, lo postearé.

12

@Giuseppe::Komenco. Siento no estar de acuerdo con tú solución ante el problema.

Nosotros llevamos con nuestros servicios SaaS desde la v7.3 y no hemos tenido problema alguno con las sucesivas versiones. Cuando decidimos el entorno de ejecución estuvimos realizando distintas pruebas sobre la evolución de las distros habituales y elegimos Ubuntu Server por considerarlo el más adecuado para los requerimientos de Qt (otras opciones fueron Fedora, RedHat, CentOS, Debian…). Descartamos RedHat y CentOS por su política de actualizaciones, Debian por su complejidad en control de versiones y política de actualizaciones. Descartamos algún otro por no ser adecuados para la visión de producto de Velneo (teníamos las experiencias de versiones anteriores 7.0, 7.1, 7.2...).

Evaluamos tres proveedores de Cloud distintos, también evaluamos otros proveedores servicios de hosting/housing, decidimos descartarlos por no ser adecuados para estos requerimientos. Por eso elegimos Amazon EC2/S3 aun siendo más caro.

No defiendo a Velneo, defiendo una forma de hacer las cosas. Cuando uno toma una decisión inapropiada paga las consecuencias. Esta decisión llevó más de tres meses de análisis y fue acertada. Si decidiste de forma inadecuada el sistema operativo para tus vServers no me eches la culpa. El que se obceca en el error eres tú, resuelve correctamente una sola vez el problema (una corrección es solo un parche ante el problema). Además no es buena, para la comunidad, la confusión. Si deseas un servicio adecuado descarta un proveedor inadecuado y utiliza una versión de S.O. adecuada para Velneo (Qt estable actualizado, por ejemplo Ubuntu).

PD: La solución que aportas siempre es bienvenida para la comunidad aun no siendo una solución con todas las garantías por no estar oficialmente testeado por Velneo.

Atentamente,
Jorge Hontoria Jiménez
http://tipesoft.com

13

@jorge

Es que creo estás mezclando hilos. Yo estoy hablando de sistema de desarrollo, donde está dando los problemas de incompatbilidad con las librerías QT, por encontrarse más de una versión en el PATH (4.7.2 incluidas con Velneo, y 4.7.3) y una solución temporal, mientras Soporte lo estudia, es eliminar las librerías de QT de la carpeta de Velneo. Ésto, para el error de "Cannot mix ...."

Por otro lado, está la parte de los servidores en producción, es el problema con las glibc. versión 2.11, lo que no tiene solución salvo reinstalar el server completo.

No llevo a la confusión por ningún sitio, digo las cosas como son. Igual que me he quejado de algo, he reculado y he ido actualizando el hilo según se iba indagando en el problema. Igual que digo, que un 10 para soporte. Al césar lo que es del cesar.

En fin, que las cosas son como son, y el cambio de glibc es una putada lo veas como lo veas, y no es un cambio en mi opinión justificable en una versión "menor".

Tienes razón, quizás tomé una decisión equivocada, pero no con el sistema servidor, si no con la herramienta quizás.

14

Como bien apuntas puede que estemos mezclando dos cuestiones fundamentales. Por un lado la parte de vServers donde mis opiniones están claramente ya expresadas. Respecto a la parte de clientes no tengo opinión alguna.

Siempre enfoqué estos comentarios desde el punto de vista del vServer, siento que alguno pueda haber mal entendido mis comentarios.

Atentamente,
Jorge Hontoria
htp://tipesoft.com