Estimados, mi ultima consulta aqui fue respecto de un cliente para jabber (y ya vieron lo que ocurrio (y esta ocurriendo)). Finalmente, se opto por openfire y spark como cliente, lejos las discusiones respecto a la performance del modelo, ya esta implementado y camina /de pelos/. Gracias a todos lo que dieron sus opiniones.
Esta vez, los molesto con otra cosa que me aflije. Tengo algunos servicios con db (mysql, db2, sql server) y existe un gran cuestionamiento: ¿como escondo las password (y usuarios) de las db a los programas y usuarios?. Es decir, pe. al configurar el acceso a mysql para un servicio web (LAMP), necesariamente debo configurar en un file la passwordm user y database que utilizare. Otro problema, y mas grande aun, en cuando tenemos aplicaciones cliente-servidor, con archivos de configuracion en cada cliente, o bien (en el caso sql server) odbc, en ese caso no existe manera de encriptar las password, y al menos debe conocerla el desarrollador/analista de la aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un archivo de configuracion. Mi problema es que necesito que estas password no sean conocidas por nadie, ni siquiera el admin del sistema (password bipartida) y el dia de mañana poder cambiarlas de manera transparente para los usuarios. He hecho monos, tirado lineas y buscado en san google, pero ando medio perdido. Espero me puedan orientar. Mis ideas me llevan a pensar que debe haber /algo/ en medio que permita la autenticacion, es decir: SERVER(user, pass)<:::::::::>**ALGO**<:::::::::>CLIENTE(user, _clave_) donde clave, es una llave, un id de instalacion, la ip de mi LAN, el usuario de dominio, etc. De antemano, muchisimas gracias. -- Saludos, LSM. Existen 10 tipos de personas: los que entienden binarios y los que no From [EMAIL PROTECTED] Wed Dec 5 14:10:37 2007 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Wed Dec 5 14:13:35 2007 Subject: Ocultar Passwords a produccion. In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Asdtaker escribió: > Otro problema, y mas grande aun, en cuando tenemos aplicaciones > cliente-servidor, con archivos de configuracion en cada cliente, o bien (en > el caso sql server) odbc, en ese caso no existe manera de encriptar las > password, y al menos debe conocerla el desarrollador/analista de la > aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un > archivo de configuracion. Mi problema es que necesito que estas password no > sean conocidas por nadie, ni siquiera el admin del sistema (password > bipartida) y el dia de mañana poder cambiarlas de manera transparente para > los usuarios. Eso es imposible. Ademas, no lograrias nada, porque el administrador de la maquina, siendo "root", podria de todos modos detener el servidor y levantarlo en el modo que no requiere password, si quisiera robarse tu informacion. Las passwords necesariamente deben estar en un archivo en alguna parte. Lo que mas puedes hacer es que dicho archivo este oculto y que nadie (salvo la aplicacion) tenga privilegios para leerlo. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "Las cosas son buenas o malas segun las hace nuestra opinión" (Lisias) From [EMAIL PROTECTED] Wed Dec 5 17:54:21 2007 From: [EMAIL PROTECTED] (Horst H. von Brand) Date: Wed Dec 5 17:57:12 2007 Subject: =?iso-8859-1?q?Re=3A_Re=3A_Re=3A_Benchmarking_en_distintos_le?= =?iso-8859-1?q?nguajes_=5B_Era_algo_as=ED_como_cliente_en_jabber?= =?iso-8859-1?q?=2E=2E=2E_=5D?= In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Aldrin Gonzalo Martoq Ahumada <[EMAIL PROTECTED]> wrote: > On Dec 3, 2007 10:59 AM, Xavier Andrade <[EMAIL PROTECTED]> wrote: > > On Sun, 2 Dec 2007, Aldrin Gonzalo Martoq Ahumada wrote: > > > Discrepo. Lo que se llama "maquina" es la definicion de una > > > arquitectura y su set de instrucciones. Cuando se habla de "maquina > > > virtual", se quiere decir que ese set de instrucciones no es el mismo > > > que el implementado en hardware; por lo tanto si quieres ejecutar ese > > > set de instrucciones requeriras de un paso de traduccion. > > > Un interprete es un programa que realiza la traduccion desde un set de > > > instrucciones o lenguaje y las ejecuta, de manera que puedas correr el > > > codigo en tu maquina "real". La distincion importante es que el paso > > > de traduccion se hace en tiempo de ejecucion; es decir, cada vez que > > > corras el programa tendras el costo adicional de traduccion lo que > > > puede traer problemas de performance o uso de recursos (memoria por > > > ej). Por eso la *implementacion* de la maquina virtual de java es un > > > interprete. > > El problema es que no es tan claro hacer la distincion, de acuerdo a tu > > definicion, x86(_64) es una maquina virtual, ya los procesadores modernos > > implementan un set de instrucciones a la RISC internamente y en el momento > > de ejecucion se traducen las instrucciones x86 a instrucciones nativas, > > algunas directamente y otras por microcodigo. > Exactamente, ese es el punto: los procesadores x86 modernos poseen un > interprete! Y, al final del dia, si el interprete del caso esta escrito en C, en assembler 6502, en el lenguaje marciano que usa el Transmeta, esta implementado en microcodigo, es la configuracion de un PLA o directamente "alambrado" en circuitos da como lo mismo... > Dicho de otra forma, si pudieramos compilar (traducir "offline") > directamente en el codigo "nativo" del procesador, nos ahorrariamos > varios ciclos de cpu (y tal vez transistores si dejamos esa pega > exclusivamente al ambiente); que se gastan en el interprete (traducir > "online"). Nopes. El procesador es /mucho/ mas rapido que la memoria hoy dia (por algo el cuento de hyperthreading, dual-core, procesadores celulares, ...). En parte por esa razon guatearon los RISC, y las arquitecturas nuevas son CISC: Claro, procesar instrucciones simples es mas rapido, pero el codigo es muchisimo menos denso (todas las instrucciones son "grandes", para hacer alguna operacion un poquitin mas compleja es media docena de instrucciones; lo mismo en CISC puede ser una sola, incluso de un solo byte); con el resultado que lo que se gana en el procesador se pierde con creces en mover instrucciones desde la memoria. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From [EMAIL PROTECTED] Wed Dec 5 17:59:13 2007 From: [EMAIL PROTECTED] (Horst H. von Brand) Date: Wed Dec 5 18:02:04 2007 Subject: =?iso-8859-1?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_?= =?iso-8859-1?q?Era_algo_as=ED_como_cliente_en__jabber=2E=2E=2E_=5D?= In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> rodrigo ahumada <[EMAIL PROTECTED]> wrote: > Horst H. von Brand <[EMAIL PROTECTED]> dijo: > [...] [Sobre C:] > > Elegante. Clasico. ;-) [Sobre C++:] > > Ni tanto mas feo que la version C. > Ambos leguajes pecan al final. Por que @#%^&[EMAIL PROTECTED] llaman "void" a > un > procedimiento? Porque en C/C++ no hay procedimientos, solo funciones; y decir que una funcion retorna "nada" es equivalente a "procedimiento". No, no es lo mas logico del mundo, pero hay cosas harto peores. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
