Re: Postgresql que se muere
El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió: On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. Saludos -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.
Re: WINE: Run-time error 7 - Out of memory
Al lanzar ipview pro (aplicacion para camaras IP) mediante wine obtengo Run-time error 7 - Out of memory Existe memoria suficiente. Creo que este no es el problema Alguien conoce este error? Algun paquete de librerías runtime que se deba instalar para aplicaciones bajo windows? Dicen que si las aplicaciones dan muchos [1]mensajes de error OLE, se puede instalar con [2]winetricks las DCOM98. En mis pruebas (wine-1.1.42 desde 0) he logrado muchos mensajes menos de error, algún mensaje de reinicio tras el instalador y errores diferentes al especificado, por lo que parece es el camino correcto. Como también [3]comentan que antiguas versiones (3.00.09) con antiguos wine (0.9.42) funcionaban, intuyo que se le puede hacer funcionar, si no la última versión, alguna de las [4]antiguas, aunque en mis pruebas los resultados han sido parecidos. También sospecho que el que logró hacer la instalación no lo hizo con Wine en vacío, sino que tendría instalado alguna cosa o librería antes. (Este párrafo tendría que ir el primero, y no el último :-) Siempre te quedará utilizar software libre, como [5]ZoneMinder, que al parecer funciona con casi todas las cámaras de [6]Trendnet. Saludos --- Angel [1]http://wiki.winehq.org/FAQ#head-4bb9daaf9091eeac20707a6904425e76ffa8ed0e [2]http://wiki.winehq.org/winetricks [3]http://appdb.winehq.org/objectManager.php?sClass=applicationiId=5635 [4]http://downloads.trendnet.com/tv-ip100_c1_1/driver_utility/ [5]http://www.zoneminder.com/ [6]http://www.zoneminder.com/wiki/index.php/Trendnet
Re: Postgresql que se muere
On Thu, 2010-07-15 at 10:03 -0400, Franco Catrin L. wrote: El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió: On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Si quieres ver el otro lado de la moneda, siempre estaran los programadores que piensan que la BD es magica y que sin importar las sentencias SQL que usen, el rendimiento debe ser maximo o superior. Las abstracciones que gotean no son un error, son un hecho. Asi es. El punto es cuanto goteo es razonable o aceptable. Hay cosas que nigun motor puede hacer, como conseguir memoria donde no la hay, pero si puede administrar bien la que tenga. Por citar el mismo ejemplo de Oracle que tu mencionaste antes, hay casos en que una consulta puede ser extremadamente lenta, pero no entrega un error de falta de memoria. Saludos
Re: WINE: Run-time error 7 - Out of memory
El Thu, 15 Jul 2010 17:09:37 +0200 AngelD ang...@froga.net escribió: Al lanzar ipview pro (aplicacion para camaras IP) mediante wine obtengo Run-time error 7 - Out of memory Existe memoria suficiente. Creo que este no es el problema Alguien conoce este error? Algun paquete de librerías runtime que se deba instalar para aplicaciones bajo windows? Dicen que si las aplicaciones dan muchos [1]mensajes de error OLE, se puede instalar con [2]winetricks las DCOM98. En mis pruebas (wine-1.1.42 desde 0) he logrado muchos mensajes menos de error, algún mensaje de reinicio tras el instalador y errores diferentes al especificado, por lo que parece es el camino correcto. Probando en mi ordenador (las pruebas anteriores eran en un Ubuntu ajeno), Debian Squeeze wine-1.0.1-2-5-g4412ca7, vete a saber con cuarta mierda instalada en el Wine (ie6, ie7, ...), con el fichero [4]IPViewPro_Setup(3.01.12).zip, y configurando un escritorio de 1024x768 para que mi gestor de ventanas no enloqueciera, todo funciona a las mi maravillas, o por lo menos el programa instala y arranca. Probando en mi ordenador, con un wine-1.0.1-2-5-g4412ca7 desde cero, con e fichero [4]IPViewPro_Setup(3.01.12).zip instala sin problemas. Al ejecutarlo me salta el instalador de Wine Gecko, y tras esto, funciona sin problemas. Así que, instala [5]ZoneMinder, o empieza a jugar con las versiones de wine para ver con cual funciona. La última vez que me toco una de estas, estuve compilando/probando con más de media docena de versiones y sus consiguientes pruebas para conseguir un resultado medianamente aceptable, pero era una aplicación del trabajo (Remedy) sin alternativas para Linux. Saludos --- Angel [1]http://wiki.winehq.org/FAQ#head-4bb9daaf9091eeac20707a6904425e76ffa8ed0e [2]http://wiki.winehq.org/winetricks [3]http://appdb.winehq.org/objectManager.php?sClass=applicationiId=5635 [4]http://downloads.trendnet.com/tv-ip100_c1_1/driver_utility/ [5]http://www.zoneminder.com/ [6]http://www.zoneminder.com/wiki/index.php/Trendnet
Re: WINE: Run-time error 7 - Out of memory
El Thu, 15 Jul 2010 17:09:37 +0200 AngelD ang...@froga.net escribió: Al lanzar ipview pro (aplicacion para camaras IP) mediante wine obtengo Run-time error 7 - Out of memory Existe memoria suficiente. Creo que este no es el problema Alguien conoce este error? Algun paquete de librerías runtime que se deba instalar para aplicaciones bajo windows? Dicen que si las aplicaciones dan muchos [1]mensajes de error OLE, se puede instalar con [2]winetricks las DCOM98. En mis pruebas (wine-1.1.42 desde 0) he logrado muchos mensajes menos de error, algún mensaje de reinicio tras el instalador y errores diferentes al especificado, por lo que parece es el camino correcto. Como también [3]comentan que antiguas versiones (3.00.09) con antiguos wine (0.9.42) funcionaban, intuyo que se le puede hacer funcionar, si no la última versión, alguna de las [4]antiguas, aunque en mis pruebas los resultados han sido parecidos. También sospecho que el que logró hacer la instalación no lo hizo con Wine en vacío, sino que tendría instalado alguna cosa o librería antes. (Este párrafo tendría que ir el primero, y no el último :-) Siempre te quedará utilizar software libre, como [5]ZoneMinder, que al parecer funciona con casi todas las cámaras de [6]Trendnet. Saludos --- Angel [1]http://wiki.winehq.org/FAQ#head-4bb9daaf9091eeac20707a6904425e76ffa8ed0e [2]http://wiki.winehq.org/winetricks [3]http://appdb.winehq.org/objectManager.php?sClass=applicationiId=5635 [4]http://downloads.trendnet.com/tv-ip100_c1_1/driver_utility/ [5]http://www.zoneminder.com/ [6]http://www.zoneminder.com/wiki/index.php/Trendnet
Re: Postgresql que se muere
On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote: El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió: On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado. Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo. Aldrin Martoq http://aldrin.martoq.cl/
Re: Movil, ¿alguna recomendación?
Creo que me voy a inclinar por le IPhone 3gs, aunque también el nokia 5800 tiene de todo e incluso es algo mejor que iphone en algunas cosas. Aun tengo tiempo para decidirme. Gracias por sus consejos. Saludos. -- Atte, Javier Andrés Garay G. Ingeniero en Informática Plug Play Net S.A. www.papnet.cl
Re: Postgresql que se muere
El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió: On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote: El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió: On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote: Eso es lo que se ve por fuera, pero el día en que inventen un SELECT que ocupe cero bytes está lejos aún. Lectura recomendada: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Yo difiero de este pensamiento. La capa extra (en este caso, la base de datos) debe ser lo suficientemente robusta para no gotear errores inesperados, pues es quien tiene toda la información de saber qué paso realmente. Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado. No entiendo la relación? Leíste el artículo completo? Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo. Por qué no? Es una situación de excepción, al igual que cuando el cliente te avisa que no se puede conectar a la base de datos. Si te fijas, el error dice que no pudo obtener la memoria que necesitaba para realizar la operación, algo que siempre puede suceder. En este caso es claro que no se justifica y el motor se confundió al estimar el tamaño, pero en el normal de los casos sí debería retornar una excepción cuando no puede hacer lo qué le estás pidiendo. ERROR: invalid memory alloc request size 1818585462 Puesto de otra forma, qué hubieras esperado que te informara el servidor si no hay suficiente memoria para realizar la operación? Datos inventados? Saludos -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.
Capas de abstracción (fue Re: Postgresql que se muere)
On Jul 15, 2010, at 3:15 PM, Franco Catrin L. wrote: El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió: On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote: Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado. No entiendo la relación? Leíste el artículo completo? Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo. Las capas de abstracción no son para protegernos de los errores, son para *solucionar un problema*. Esto implica que son buenas para cierto ámbito (no para todas) pues están diseñadas para hacer tal o cual cosa. Y deben hacerlo bien. En tu ejemplo del artículo, supongamos que es una biblioteca que le paso una lista y tiene una operación que hace algo con ella (por ejemplo, ordenarla). Siguiendo el ejemplo, tenemos un caso en que tiene la operación tiene muy mal rendimiento (por cómo está construida la biblioteca justo la mala suerte). La postura del artículo es que la biblioteca nos protege o facilita de lo complicado que es el mundo real (el problema de ordenar una lista), por eso a veces te toca bailar con la fea. Pero si cuando construimos la biblioteca, lo que se pidió era resolver el problema de ordenar una lista de manera rápida, entonces el problema es otro: se ignoró dicho requisito (puede ser ambas partes: quien usa la biblioteca como quien la construye, o ambos). Es como si llevas el auto a un mecánico y te comienza a chamullar con miles de dramas (no, que ahora tuve este problema, no que ahora se quemó no se que cosa)... puras excusas, pues le pagas al mecánico para resolver tal problema. Si el mecánico no puede preveer este tipo de dramas, está dando un pésimo servicio; hay veces en que esto sucede, pero lo que debe pasar es que el te advierte antes. Algo similar sería que la biblioteca del ejemplo nunca fue declarada performante. De ahí el herramienta adecuada, ¿ves? Por el otro lado, si la biblioteca sí fue declarada como performante, esto es un bug... nada de andar chamullando con leaky abstractions o lo complicado que es la vida. Hay millones de ejemplos en la vida real: ir al mecánico, que un doctor te opere de la vesícula, cuando haces un trámite en el banco... Que algo del mundo real falle no es excusa para dar un mal servicio, es lo mismo con una capa de software. Por qué no? Es una situación de excepción, al igual que cuando el cliente te avisa que no se puede conectar a la base de datos. Si te fijas, el error dice que no pudo obtener la memoria que necesitaba para realizar la operación, algo que siempre puede suceder. En este caso es claro que no se justifica y el motor se confundió al estimar el tamaño, pero en el normal de los casos sí debería retornar una excepción cuando no puede hacer lo qué le estás pidiendo. ERROR: invalid memory alloc request size 1818585462 Puesto de otra forma, qué hubieras esperado que te informara el servidor si no hay suficiente memoria para realizar la operación? Datos inventados? Es todo lo contrario: nosotros estamos inventando (como tu bien dices) qué fue lo que paso. En cambio, postgresql (o nuestra capa de abstracción) está en la fuente del error... tiene toda la información a mano que puede perfectamente desplegar; el ejemplo claro es que si es el campo de un índice cuyo tamaño se fue a las pailas, podría dar el nombre del desdichado. ¡Si para eso le pago al mecánico! Y de hecho, una vez que comienzas a ver mas seguido estaría mas claro el siguiente problema: por qué se corrompen los índices y/o cómo evitarlo... Aldrin Martoq http://aldrin.martoq.cl/
Re: WINE: Run-time error 7 - Out of memory
El 15-07-2010 11:09, AngelD escribió: Al lanzar ipview pro (aplicacion para camaras IP) mediante wine obtengo Run-time error 7 - Out of memory Existe memoria suficiente. Creo que este no es el problema Alguien conoce este error? Algun paquete de librerías runtime que se deba instalar para aplicaciones bajo windows? Dicen que si las aplicaciones dan muchos [1]mensajes de error OLE, se puede instalar con [2]winetricks las DCOM98. En mis pruebas (wine-1.1.42 desde 0) he logrado muchos mensajes menos de error, algún mensaje de reinicio tras el instalador y errores diferentes al especificado, por lo que parece es el camino correcto. Si, instale winetricks, pero tiene mas de 80 librerias runtime .. ni loco probaré una por una.. además, no el mensaje de runtime podría estar equivocado y quizas es una dll la que no puede registrar su clase. quien sabe. Mejor instale una maquina virtual y corrí la aplicación deseada, para tener conectividad solo puse la interfaz en modo bridge y ahora tengo el servidor de Camaras IPVIEW corriendo desde una ventana windows, dentro de linux, trabaja estupendo. Me gustaría resolver el problema con wine si... me pongo nervioso teniendo esa MV alli ;-) = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Capas de abstracción (fue Re: Postgresql que se muere)
El jue, 15-07-2010 a las 16:19 -0400, Aldrin Martoq escribió: On Jul 15, 2010, at 3:15 PM, Franco Catrin L. wrote: El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió: On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote: Mi mirada al documento es respecto a cómo las abstracciones pueden jugar en contra cuando no sabes qué está pasando realmente por debajo, algo que queda claro al leer los comentarios en este thread. Un buen ejemplo que da el autor es cuando recorres una estructura de datos y perfectamente el programador puede recorrerla de una forma que el rendimiento se degrade. Las abstracciones que gotean no son un error, son un hecho. No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado. No entiendo la relación? Leíste el artículo completo? Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo. Las capas de abstracción no son para protegernos de los errores, son para *solucionar un problema*. Esto implica que son buenas para cierto ámbito (no para todas) pues están diseñadas para hacer tal o cual cosa. Y deben hacerlo bien. En tu ejemplo del artículo, supongamos que es una biblioteca que le paso una lista y tiene una operación que hace algo con ella (por ejemplo, ordenarla). Siguiendo el ejemplo, tenemos un caso en que tiene la operación tiene muy mal rendimiento (por cómo está construida la biblioteca justo la mala suerte). La postura del artículo es que la biblioteca nos protege o facilita de lo complicado que es el mundo real (el problema de ordenar una lista), por eso a veces te toca bailar con la fea. Pero si cuando construimos la biblioteca, lo que se pidió era resolver el problema de ordenar una lista de manera rápida, entonces el problema es otro: se ignoró dicho requisito (puede ser ambas partes: quien usa la biblioteca como quien la construye, o ambos). El ejemplo va por otro lado. Como programadores asumimos que la memoria es lineal y cada celda tiene el mismo costo de acceso. Esa es la abstracción. La realidad es que la memoria puede estar fragmentada y además tienes sistemas de caché intermedios, por lo que no existe un costo de acceso igual para todos los casos. Cómo una biblioteca te puede proteger de eso si como programador necesitas por ejemplo un array bidimensional que vas a procesar por filas y por columnas indistintamente? Es como si llevas el auto a un mecánico y te comienza a chamullar con miles de dramas (no, que ahora tuve este problema, no que ahora se quemó no se que cosa)... puras excusas, pues le pagas al mecánico para resolver tal problema. Si el mecánico no puede preveer este tipo de dramas, está dando un pésimo servicio; hay veces en que esto sucede, pero lo que debe pasar es que el te advierte antes. Algo similar sería que la biblioteca del ejemplo nunca fue declarada performante. De ahí el herramienta adecuada, ¿ves? Por el otro lado, si la biblioteca sí fue declarada como performante, esto es un bug... nada de andar chamullando con leaky abstractions o lo complicado que es la vida. En ese caso, si le pagas al mecánico por resolver un problema puntual, lo puede hacer perfectamente, otra cosa muy distinta es querer que te deje el auto andando. Es la clásica confusión entre el que define los requerimientos y el que los tiene que satisfacer. Hay millones de ejemplos en la vida real: ir al mecánico, que un doctor te opere de la vesícula, cuando haces un trámite en el banco... Que algo del mundo real falle no es excusa para dar un mal servicio, es lo mismo con una capa de software. Qué me dices del ejemplo en donde los sistemas de seguridad de un auto no ocultan la diferencia entre manejar con o sin lluvia? La capa de software o los servicios siempre tienen un límite en donde no pueden resolver los problemas por si mismos. Es ahí donde salta la excepción. Que estén o no declarados esos límites es otro problema muy distinto, y al final la elegancia con que se resuelven algunos casos puede ser inútil en la práctica, aumentando el costo para el 99% de los casos sólo por el 1% de los casos (o menos). En mi opinión la perfección tiene un costo que tiende a infinito. Por qué no? Es una situación de excepción, al igual que cuando el cliente te avisa que no se puede conectar a la base de datos. Si te fijas, el error dice que no pudo obtener la memoria que necesitaba para realizar la operación, algo que siempre puede suceder. En este caso es claro que no se justifica y el motor se confundió al estimar el tamaño, pero en el normal de los casos sí debería retornar una excepción cuando no puede hacer lo qué le estás pidiendo. ERROR: invalid memory alloc request
