Es amd64 para servidor en produccion ?
On Thu, 17 Jul 2008, Horst H. von Brand wrote: Xavier Andrade [EMAIL PROTECTED] wrote: [...] PowerPC 64, Ultrasparc y x86-64 son todas arquitecturas que pueden ejecutar dos ISAs nativamente, la de 32 bits y la de 64. A eso te refieres? Mentira. x86_64 puede ejecutar codigo de 16 bits tambien (si no, ni modo bootea Windows ;-) En ningun momento dije que podian ejecutar _solo_ 2 ISAs, asi que lo que dije no es mentira ;-) De todas formas, en x86-64 corriendo un nucleo de 64 bits no se puede ejecutar codigo de 16 bits. Xavier From [EMAIL PROTECTED] Fri Jul 18 10:53:54 2008 From: [EMAIL PROTECTED] (dblackbeer) Date: Fri Jul 18 11:20:49 2008 Subject: error_directory en squid26 modo transparente Message-ID: [EMAIL PROTECTED] Quiero redirigir a un html cuando no hay conexion a internet. Lo hago con error_directory. Funciona bien mientras configure manualmente el proxy en el navegador. Al hacerlo de manera transparente recibo el mensaje del navegador. Alguna sugerencia? Desde ya muchas gracias. -- cosechero :wq! From [EMAIL PROTECTED] Fri Jul 18 11:54:19 2008 From: [EMAIL PROTECTED] (Horst H. von Brand) Date: Fri Jul 18 11:55:31 2008 Subject: copiando LV entre servidores In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Victor Hugo dos Santos [EMAIL PROTECTED] wrote: que alternativas existen para copiar un Volume Logico desde un servidor a otro, sin reiniciar ??? Usaria rsync(1). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 From [EMAIL PROTECTED] Fri Jul 18 12:15:38 2008 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Fri Jul 18 12:15:47 2008 Subject: copiando LV entre servidores In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Horst H. von Brand escribió: Victor Hugo dos Santos [EMAIL PROTECTED] wrote: que alternativas existen para copiar un Volume Logico desde un servidor a otro, sin reiniciar ??? Usaria rsync(1). Para eso, mejor OCFS o algo asi ... -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 Postgres is bloatware by design: it was built to house PhD theses. (Joey Hellerstein, SIGMOD annual conference 2002) From [EMAIL PROTECTED] Fri Jul 18 13:10:48 2008 From: [EMAIL PROTECTED] (Mauricio Vergara Ereche) Date: Fri Jul 18 13:10:52 2008 Subject: DNS bug In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] On Thursday 17 July 2008 18:00:51 Alvaro Herrera wrote: Horst H. von Brand escribió: Segun entiendo, en Linux esa aleatorizacion la hace el nucleo sin requerir intervencion de la aplicacion, asi que en principio aca no habria problema. Claro que no se ha dicho exactamente cual es el problema, asi que... El problema *es* grave... los detalles los dará a conocer Kaminski en el Black Hat de Agosto. Hasta el momento no hay exploit dando vuelta en el público, porque aún se espera que todos parchen sus servidores recursivos. (La gente que usa bind, buscando sus versiones *-P1, otra alternativa es ocupar unbound de NLnetlabs). En cuanto al kernel de linux, aún no está muy claro si el problema afecta o no al núcleo... Florian Weiner (un destacado investigador del mundo DNS) al menos publicó lo siguiente: http://seclists.org/fulldisclosure/2008/Jul/0070.html Por lo que leí, la única implementación que no era vulnerable era djbdns de Dan Bernstein. y la de unbound En el blog del investigador se comentaba que Paul Vixie estaba algo avergonzado de haber tenido que darle la razón a DJB en este tema :-) Una nota/entrevista al respecto de Vixie: http://www.circleid.com/posts/87143_dns_not_a_guessing_game Saludos! -- Mauricio Vergara Ereche User #188365 counter.li.org NIC Chile mave [EMAIL PROTECTED] nic [.] cl Miraflores 222 piso 14, Santiago CHILE+56 2 9407710 Codigo Postal: 832-0198 http://www.nic.cl
Es amd64 para servidor en produccion ?
en la práctica pocos softwares sacan provecho real de los 64bits, como alguien ya dijo incluso en algunos casos es más lento que en 32bits en realidad solo conozco un par de softwares que se benefician de manera increíble con los 64 bits, uno de esots es el mathlab que incrementa su rendimiento al doble. el resto la verdad no gana mucho si corre en 64 o 32 bits.. y la real ganancia de usar un SO de 64 bits es el poder asignar más de 2gb de ram a un solo thread. (excepto estos 2 o 3 softwares que sacan real provecho de los 64bits) desde que aparecieron los 64 bits en procesadores caseros, el primero fue el AMD 64. y en sus features ya decía que soporta WOW, que se traduce como windows on windows, en la practica esto significa que un sistema operativo de 64bits, corriendo en uno de estos procesadores, puede correr software de 32bits sin problemas, el único requisito es que todo lo que corre a nivel del kernel sea de 64bits (hay algunas excepciones, como flashplayer y otros, pero en general puede correr casi todo software de 32bits) El 09-07-2008, a las 15:42, Daniel Serpell escribió: Hola! El Mon, Jul 07, 2008 at 01:46:35PM -0400, Aldrin Martoq escribio: [...] Ambos mundos 32bits y 64 bits tienen ventajas y desventajas respecto de las aplicaciones actuales. Por lo tanto, lo que digo es que no deberiamos tener distros 64bits y otras 32bits; sino que el default debiera ser 32bits y solo las aplicaciones que se beneficien tengan la opcion 64bits. Lamentablemente, eso no es tan simple como parece. Pese a que los vendedores de CPUs quieren hacer creer lo contrario, los modos de 64 bits y 32 bits *no* son compatibles entre ellos en la arquitectura. Si el núcleo (código a nivel supervisor) corre en modo 32 bits, no se puede ejecutar código de usuario en 64 bits. Por esto, si quieres tener aplicaciones de 64 bits, necesitas un núcleo de 64 bits - esto es un kernel compilado para AMD64. Ahora viene el segundo problema: los controladores de hardware que corren en el núcleo deben estár compilados también para AMD64. Esto significa que los que utilizan drivers binarios deben conseguir estos drivers para 64bits. Luego de convertir el núcleo y los drivers, viene el problema número 3: las aplicaciones que acceden al hardware desde modo usuario también necesitan saber que el núcleo es de 64 bits - es el caso del X. Esto es necesario ya que la CPU ve al hardware de manera distinta cuando se encuentra en modo 64 bits - la principal diferencia es que al ser mayor el rango de direcciones el hardware se mapea a travez de una MMU de entrada/salida - la IOMMU. Bueno, por lo pronto tenemos entonces: * Kernel de 64 bits. * Drivers de 64 bits. * X en 64 bits * Bibliotecas del X (para que X funcione) de 64 bits. Todo esto en RAM, utilizando recursos. ¿Para qué entonces quieres ahora tener alguna aplicación en 32 bits? Si es por compatibilidad, eso no es problema. Las aplicaciones normales de 32 bits corren sin problema, basta tener instaladas las bibliotecas de 32 bits al lado de las de 64. Si es por velocidad, las aplicaciones compiladas nativamente para 64 bits son más rápidas, sobre todo porque la ABI de 64 bits es mejor - permite el paso de más argumentos en registros y utiliza los registros de XMM para punto flotante, no el stack de FPU antiguo. Si es por tamaño del código - algo sensible si se pretende maximizar la utilización de los cachés L1 de la CPU - en realidad ahorras un 20% en promedio - un ejemplo con un pequeño programa: $ gcc -m64 -O2 -fomit-frame-pointer -Wall -c -o ff-x86-64.o ff.c $ gcc -m32 -O2 -fomit-frame-pointer -Wall -c -o ff-x86.o ff.c $ size ff-x86* text databssdechex filename 11960 0 18 11978 2eca ff-x86-64.o 10067 0 10 10077 275d ff-x86.o Finalmente, todo se reduce a: * El plugin propietario de Flash que no funciona bien en 64 bits: Al menos en mi casa parece funcionar bien (osea, igual de mal que en mode 32 bits) en Ubuntu 8.04. * El soporte de drivers para cierto hardware: Idem, al menos en mi caso todo el hardware anda bien. * Aplicaciones muy antiguas, que hacen suposiciones acerca del hardware específicas (mencionabas Linuxthreads). En modo 64 bits, debido a las incompatibilidades de la arquitectura, ni modo :-( - PD: Respecto al soporte de más memoria utilizando PAE, la principal desventaja es que para el I/O debes tener buffers en memoria baja para realizar DMA desde los dispositivos. Eso implica que el kernel debe mover memoria de un lado a otro para llenar la memoria alta desde disco o red - bastante costoso en rendimiento. - Daniel.
Es amd64 para servidor en produccion ?
2008/7/7 Alvaro Herrera [EMAIL PROTECTED]: Aldrin Martoq escribió: No todo es ganancia en 64bits. Dudo que firefox necesite mas de 3GB de RAM y/o punteros o calculos grandes. Y pierdes en el cache L1/L2. Entonces, el punto es que debiera ser todo 32-bits por default y solo algunas aplicaciones que lo requieran la opcion de 64 bits. Firefox no necesita mas de 3 GB? Creo que los desarrolladores estarían en desacuerdo ;-) Mi comentario iba al kernel en todo caso. El kernel tiene que ser de 64 bits: para que pueda aprovechar bien la memoria, usar los tipos mas gordos con un solo registro en lugar de dos (por ej. en el filesystem hay direccionamiento de 48 bits en algunas partes sin no me equivoco), etc. El resto de las cosas, da lo mismo y puedes escoger libremente, pero la ganancia por tener los registros extra facilmente puede ser mayor que la perdida por tener datos mas anchos. Bueno, no es requisito que el kernel sea 32bits tampoco! Es solo la implementacion que se hizo en Linux, con unos cuantos parches (muy posiblemente no triviales) podrias correr un kernel 32bits, algunas cosas criticas como direcciones 64bits en vez de PAE y aplicaciones 32/64bits. MacOS tiene un kernel 32bits por otros factores: soporte de drivers. En particular, a mi me parece perfecto que se quiebre la compatibilidad con software propietario; PERO un kernel 32bits con soporte 64 bits seria una gran ventaja... sigue leyendo: Ese es el problema, reemplazaron todo lo que estaba en /lib es 64 bits y hay que instalar ia32-libs ... el default debiera ser al reves, /lib es 32 bits y /lib-64 64bits o algo por el estilo. Las aplicaciones lo mismo, que sentido tener bash 64bits? etc... No entiendo lo que dices. Da lo mismo dónde estén las bibliotecas. Lo importante es que el linker las encuentre. Si al compilar Firefox le das las opciones al compilador para que genere un ejecutable de 32 bits, va a funcionar correctamente, sin tener que hacerle nada especial al sistema, sin tener que mover bibliotecas. Ahora, si la distro empaqueta Firefox para amd64 en 64 bits o en 32, ya es otro cuento. Hay dos temas: uno tecnico y otro de efecto de las decisiones tecnicas. En la parte tecnica Linux soporta un kernel 64bits y ejecutar aplicaciones 32/64 bits. En la parte del efecto de las decisiones tecnicas esta el problema. Hoy todos te dicen no instales 64 bits, no ganas nada en tu laptop y mas encima muchas cosas dejaran de funcionar. Eso es un error en mi opinion: alejar usuarios reduce la presion por mejorar algo y por lo tanto ralentiza la innovacion. O given enough eyeballs, all bugs are shallow como se decia antes. Se esta privando de las ventajas de 64bits a muchos usuarios. Ahora imagina el esquema que estoy proponiendo: la distro completa por omision corre 32bits, pero puedes instalar una aplicacion 64bits si eso implica una ganancia. Los usuarios no tendrian dudas de instalar la version 32 o 64 bits, pues seria una sola. Las aplicaciones que realmente se benefician de amd64 (no solo los 64 bits, sino la mayor cantidad de registros y otras cosas que desconozco) el usuario (o la distro) podria optar por instalar las aplicaciones 64bits recomendadas. Como determinar las aplicaciones 64bits-recomendadas? si los que empaquetan ffmpeg detectan que mejora el performance en 64 bits, ffmpeg seria una aplicacion recomendada. Tecnicamente, esto se podria hacer bastante facil: dejar /lib /bin con 32bits como ahora, dejar /lib-64 y /bin-64 con 64 bits. No hay necesidad que el linker adivine cual .so tienes que linkear, las aplicaciones en /bin-64 apuntan a /lib-64/libc-6.so y las en /bin apuntan a /lib/libc-6.so. El usuario ejecuta firefox y si tiene /bin-64 en su PATH se ejecutara siempre la de 64bits y opcionalmente el podria ejecutar el firefox 32bits si tambien lo tiene instalado. Ahora, si existiera un kernel 32 bits que active features 64bits en demanda, seria la panacea. Ahi bastaria una sola distro, un solo kernel y nadie tendria dudas de que cosa instalar! Todos estarian usando la misma distro; cuando hay ganancia las aplicaciones 64 bits; habria mas presion por optimizar la perfomance de las aplicaciones de 64 bits! El instalador de ubuntu podria automagicamente instalar por default las versiones 64 bits de las aplicaciones recomendadas (ffmpeg, postgres, etc) si detecta que tu CPU soporta 64 bits. Y ademas, si quieres instalar algo 32 bits no seria un cacho como lo es hoy, ya que es el mismo esquema para el resto de los tarros. [...] No he probado que pasa instalando Firefox de 32 bits aca, pero mi impresion es que si instalas los paquetes de las bibliotecas necesarias, deberia funcionar. Puedes probar y contarnos? ;) Lo ideal seria ver alguna diferencia Bueno, el problema de como esta disengado ahora es que hacer eso no es trivial y puede involucrar chroot's y cosas horribles... ffmpeg sí tiene código ASM optimizado por arquitecturas, puedes mirarlo acá:
Es amd64 para servidor en produccion ?
On Mon, 7 Jul 2008, Aldrin Martoq wrote: Xavier, Cual seria la diferencia con un kernel 32 bits PAE en performance? No soy un experto, pero por lo que entiendo PAE es un hack de Intel que agrega 4 bits a las direcciones de memoria fisicas, manteniendo 32 bits para las direcciones de memoria virtuales. Entonces el kernel puede accesar hasta 64 Gb de memoria, pero cada proceso solo puede accesar 4 Gb. Hasta aca no hay problemas de rendimiento. Pero para usar mas memoria tienes que usar varios procesos, o usar algun truco (por ejemplo con mmap) para reutilizar el espacio de direcciones. Esto es lo que conlleva problemas de rendimiento, y lo mas importante, complica la programacion. Saludos, Xavier
Es amd64 para servidor en produccion ?
On Tue, 8 Jul 2008, Aldrin Martoq wrote: Hay dos temas: uno tecnico y otro de efecto de las decisiones tecnicas. En la parte tecnica Linux soporta un kernel 64bits y ejecutar aplicaciones 32/64 bits. En la parte del efecto de las decisiones tecnicas esta el problema. Hoy todos te dicen no instales 64 bits, no ganas nada en tu laptop y mas encima muchas cosas dejaran de funcionar. Eso es un error en mi opinion: alejar usuarios reduce la presion por mejorar algo y por lo tanto ralentiza la innovacion. O given enough eyeballs, all bugs are shallow como se decia antes. Se esta privando de las ventajas de 64bits a muchos usuarios. Ahora imagina el esquema que estoy proponiendo: la distro completa por omision corre 32bits, pero puedes instalar una aplicacion 64bits si eso implica una ganancia. Los usuarios no tendrian dudas de instalar la version 32 o 64 bits, pues seria una sola. Las aplicaciones que realmente se benefician de amd64 (no solo los 64 bits, sino la mayor cantidad de registros y otras cosas que desconozco) el usuario (o la distro) podria optar por instalar las aplicaciones 64bits recomendadas. Como determinar las aplicaciones 64bits-recomendadas? si los que empaquetan ffmpeg detectan que mejora el performance en 64 bits, ffmpeg seria una aplicacion recomendada. Tecnicamente, esto se podria hacer bastante facil: dejar /lib /bin con 32bits como ahora, dejar /lib-64 y /bin-64 con 64 bits. No hay necesidad que el linker adivine cual .so tienes que linkear, las aplicaciones en /bin-64 apuntan a /lib-64/libc-6.so y las en /bin apuntan a /lib/libc-6.so. El usuario ejecuta firefox y si tiene /bin-64 en su PATH se ejecutara siempre la de 64bits y opcionalmente el podria ejecutar el firefox 32bits si tambien lo tiene instalado. Ahora, si existiera un kernel 32 bits que active features 64bits en demanda, seria la panacea. Ahi bastaria una sola distro, un solo kernel y nadie tendria dudas de que cosa instalar! Todos estarian usando la misma distro; cuando hay ganancia las aplicaciones 64 bits; habria mas presion por optimizar la perfomance de las aplicaciones de 64 bits! El instalador de ubuntu podria automagicamente instalar por default las versiones 64 bits de las aplicaciones recomendadas (ffmpeg, postgres, etc) si detecta que tu CPU soporta 64 bits. Y ademas, si quieres instalar algo 32 bits no seria un cacho como lo es hoy, ya que es el mismo esquema para el resto de los tarros. Pero el esquema que describes es lo ideal, el problema es que necesitas un sistema de paquetes inteligente, capaz de soportar varias arquitecturas instaladas al mismo tiempo y esa es la razon por la que este esquema no se ha adoptado en Debian, pero se supone que estan trabajando en ello (hace mucho tiempo, no se cual es el estatus actual). Como habia gente que no queria esperar para tener un sistema de 64 bits (todo por el mito de la potencia de los 64 bits) hicieron un port a amd64 recompilando todo (originalmente se llamaba pure 64), que despues paso a ser oficial. Pero no es necesario un kernel de 32 bits con extensiones, simplemente se puede usar uno de 64 bits. Respecto al uso en desktop, el principal problema son las aplicaciones no libres que vienen en binario, ya que la mayoria de las empresas no ha sacado versiones de 64 bits. Pero a medida que las maquinas comunes empiezen a venir con mas RAM los usuarios tendran mas razones para migrar. Saludos, Xavier From [EMAIL PROTECTED] Tue Jul 8 12:43:07 2008 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Tue Jul 8 12:43:15 2008 Subject: Es amd64 para servidor en produccion ? In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Xavier Andrade escribió: On Mon, 7 Jul 2008, Aldrin Martoq wrote: Xavier, Cual seria la diferencia con un kernel 32 bits PAE en performance? No soy un experto, pero por lo que entiendo PAE es un hack de Intel que agrega 4 bits a las direcciones de memoria fisicas, manteniendo 32 bits para las direcciones de memoria virtuales. Entonces el kernel puede accesar hasta 64 Gb de memoria, pero cada proceso solo puede accesar 4 Gb. Hasta aca no hay problemas de rendimiento. Hmm, por lo que recuerdo, cada vez que hay un cambio en los 4 high bytes de la direccion, hay que hacer un flush del TLB, lo cual es caro. -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ El conflicto es el camino real hacia la unión From [EMAIL PROTECTED] Tue Jul 8 14:23:46 2008 From: [EMAIL PROTECTED] (Aldrin Martoq) Date: Tue Jul 8 14:23:50 2008 Subject: Es amd64 para servidor en produccion ? In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED
Es amd64 para servidor en produccion ?
On Sun, 2008-07-06 at 05:44 +0200, Rodrigo Fuentealba wrote: 2008/7/6 Aldrin Martoq [EMAIL PROTECTED]: Yo no tengo idea porque no he tenido un laptop 64bits para jugar... pero la sensacion que tengo es que estamos un poco atrasados al respecto. Si lo estamos. No aprovechamos toda la potencia de los 64 bits. Y es porque muchos de los dispositivos que usamos aun son de 32 bits. El problema radica en que tenemos solo la opcion de blanco o negro (64bits o 32bits) pero no hay grises. Y eso implica cambiar/usar un kernel distinto, drivers distintos (ej: graficos nvidia), bibliotecas distintas (/lib*) y aplicaciones distintas. Pero si tenemos grises, me suena un poco al funcionamiento de Wine, por ende un programa de 32 bits ira mas lento que uno de 64. Ambos mundos 32bits y 64 bits tienen ventajas y desventajas respecto de las aplicaciones actuales. Por lo tanto, lo que digo es que no deberiamos tener distros 64bits y otras 32bits; sino que el default debiera ser 32bits y solo las aplicaciones que se beneficien tengan la opcion 64bits. En general hay varias cosas que no funcionan bien. Hace un año intente armar un servidor 64bits virtualizado con Xen y corriendo software IBM y en particular dicho software no funciono... y la distro (debian) tenia varios problemas tambien que eran particulares a esa version. La maquina tenia 16GB RAM y Linux 32bits si soporta mas de 4GB, pero es mas lento... Que software? IBM WebSphere 5.algo ... (app server, MQ, DB2 7.algo, etc). Yo hice varias maquinas virtuales con software de 32 y 64 bits corriendo encima, en una maquina de 32, y no tuve problema alguno. Bueno, ese software es _dificil_ hacerlo correr en una distro actual (de partida habia que tener LinuxThreads cosa que nadie trae hoy). En la practica, solo funciono en la misma version de Debian de 32bits pero no en la de 64bits. Hay cosas parecidas con el flash player de adobe segun he leido, pero no se los detalles de porque ocurre esto. -- Aldrin Martoq [EMAIL PROTECTED] http://aldrinvideopodcast.podshow.com/
Es amd64 para servidor en produccion ?
On Sun, 2008-07-06 at 12:21 +0200, Xavier Andrade wrote: On Sat, 5 Jul 2008, Aldrin Martoq wrote: Yo estoy seguro que en ambientes gigantes (procesos con harto uso de memoria, bases de datos gigantes o algunos procesos) se esta aprovechando bien linux x86-64. Hay algunos calculos que se ejecutan mas rapido en 64bits por ejemplo. Pero de ahi hacia abajo hasta el notebook tuyo el soporte es con varios problemas y baches... En el caso de las aplicaciones de calculo numerico si hay una ventaja por los 64 bits, ya que hay 8 registros extra. Pero esto no es algo inherente a los 64, sino AMD aprovecho la extension de la ISA para poner mas registros (lastima que solo se quedaron en 16 y no subio al menos a 32). Bueno, cuando hablamos de x86-64, amd64 o intel64 nos referimos al procesador en particular mas que 64bits... Deben haber muchas otras mejoras, la mayor cantidad de registros mejora el paso de parametros y las aplicaciones tambien se benefician de esto... De todas formas, para sistemas de escritorio y laptops no tiene mucho sentido usar distribuciones de 64 bits, hay varios programas propietarios que no correr directamente y que es mas complicado hacer andar (los principales son el flash player de adobe y skype). Estoy seguro que hay aplicaciones que se beneficiarian y no se han hecho por esta distincion de no para el desktop... Hacer un mmap de un archivo de video por ejemplo? -- Aldrin Martoq [EMAIL PROTECTED] http://aldrinvideopodcast.podshow.com/
Es amd64 para servidor en produccion ?
On Mon, 2008-07-07 at 02:07 +0200, Xavier Andrade wrote: On Sun, 6 Jul 2008, Hector Gatica wrote: El escenario es basicamente servidor web y de correo (postfix virtual users , apache2 , postgresql , mysql). Tengo un par de servidores con 500 y 1000 usuarios correspondientemente y he notado alta carga a ratos. Quiero hace upgrade de memoria de 4gb (actual) a 8gb. Y aprovechar de hacer un upgrade de cpu que tiene un p4 3.4 a un quad core con más cache (sé que no es la mejor maquina pero , hasta el momento era suficiente). Quiero ver si haciendo este upgrade será conveniente pasar a 64bits (amd64). Mejor es medir el performance antes de hacer el cambio. ?Puede ser mayoritariamente disco duro por ejemplo, asi cambiar de CPU no solucionara tu problema! Una forma sencilla es SAR, aca en ubuntu el paquete se llama atsar: # apt-get install atsar Eso deja un cron con el cual apareceran archivos de texto en /var/log/atsar. Dejalo un par de dias con uso normal y veras mas o menos donde esta el problema. Tambien hablaste algo de streaming audio/video... que estas usando? No se si FFmpeg incorpora optimizaciones para 64bits... Con esas cantidades de memoria es mejor que uses 64 bits. Respecto a las aplicaciones, todas esas deberian funcionar sin problemas. Xavier, Cual seria la diferencia con un kernel 32 bits PAE en performance? -- Aldrin Martoq [EMAIL PROTECTED] http://aldrinvideopodcast.podshow.com/
Es amd64 para servidor en produccion ?
On Mon, 7 Jul 2008, Aldrin Martoq wrote: Bueno, ese software es _dificil_ hacerlo correr en una distro actual (de partida habia que tener LinuxThreads cosa que nadie trae hoy). En la practica, solo funciono en la misma version de Debian de 32bits pero no en la de 64bits. Hay cosas parecidas con el flash player de adobe segun he leido, pero no se los detalles de porque ocurre esto. El flashplayer de Adobe viene solo en binario para x86, para correrlo en 64 bits es necesario un wrapper llamado npviewer. Instalarlo, en Debian al menos, es transparente pero a veces se cuelga y consume considerablemente mas cpu que corriendo directamente en 32 bits (viendo videos en flash, por ejemplo). Xavier From [EMAIL PROTECTED] Mon Jul 7 14:51:53 2008 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Mon Jul 7 14:52:08 2008 Subject: Es amd64 para servidor en produccion ? In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Xavier Andrade escribió: On Mon, 7 Jul 2008, Aldrin Martoq wrote: Bueno, ese software es _dificil_ hacerlo correr en una distro actual (de partida habia que tener LinuxThreads cosa que nadie trae hoy). En la practica, solo funciono en la misma version de Debian de 32bits pero no en la de 64bits. Hay cosas parecidas con el flash player de adobe segun he leido, pero no se los detalles de porque ocurre esto. El flashplayer de Adobe viene solo en binario para x86, para correrlo en 64 bits es necesario un wrapper llamado npviewer. Instalarlo, en Debian al menos, es transparente pero a veces se cuelga y consume considerablemente mas cpu que corriendo directamente en 32 bits (viendo videos en flash, por ejemplo). Ojo que el problema aquí es que el plugin es básicamente una biblioteca de 32 bits, y el browser es un programa de 64. Como es imposible tener ambos funcionando directamente en el mismo proceso, lo que hace npviewer es correr la biblioteca en un proceso aparte y comunicar entre los dos haciendo las conversiones necesarias. Estas conversiones extras son las que usarían mas CPU. Acá en mi tarro ese consumo extra de CPU no se nota (claro que es un X2) -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ Ni aun el genio muy grande llegaría muy lejos si tuviera que sacarlo todo de su propio interior (Goethe) From [EMAIL PROTECTED] Mon Jul 7 14:55:36 2008 From: [EMAIL PROTECTED] ([EMAIL PROTECTED]) Date: Mon Jul 7 14:55:51 2008 Subject: Correo In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Estimados Gusto en saludarles. Quiero enviar correo desde linea de comandos bash y me funciona bien para el envío de correos locales. No obstante para los que envio hacia fuera del servidor, @cualquiercosa.com, no llegan. En el syslog aparece el siguiente mensaje: sendmail[24568]: [ID 801593 mail.info] m67Gtmib024568: to= [EMAIL PROTECTED], delay=00:00:00, mailer=esmtp, pri=30093, dsn=4.4.3, stat=queued Cómo puedo configurar el mail para que envíe correos hacia fuera de la organización? o, de otra manera, qué herramienta existe para enviar correos desde linea de comando utilizando un smtp externo? Muchas gracias de antemano. Prueba con el comando nail, esta es la sintaxis que yo uso: nail -r [EMAIL PROTECTED] -s Some subject -S smtp=some.smtp.server [EMAIL PROTECTED] msg.txt Mmmm, no tengo nail en la máquina y al ir a buscarlo a SourceForge ya no estaba. No creo que convenga poner un programa que ya salió de circulación en un server. Por otro lado, le puse verbose al mail y este ese el mensaje de error que arroja: xx.cl: Name server timeout ... Transient parse error -- message queued for future delivery ... queued
Es amd64 para servidor en produccion ?
El Lunes 07 Julio 2008, Xavier Andrade escribió: On Mon, 7 Jul 2008, Aldrin Martoq wrote: Bueno, ese software es _dificil_ hacerlo correr en una distro actual (de partida habia que tener LinuxThreads cosa que nadie trae hoy). En la practica, solo funciono en la misma version de Debian de 32bits pero no en la de 64bits. Hay cosas parecidas con el flash player de adobe segun he leido, pero no se los detalles de porque ocurre esto. El flashplayer de Adobe viene solo en binario para x86, para correrlo en 64 bits es necesario un wrapper llamado npviewer. Instalarlo, en Debian al menos, es transparente pero a veces se cuelga y consume considerablemente mas cpu que corriendo directamente en 32 bits (viendo videos en flash, por ejemplo). Flash igual consume considerables cantidades de CPU en x86, por algo quieren acelerarlo con la GPU. En cualquier caso instalar un navegador de 32 bits y ejecutar flash dentro no tienen ninguna dificultad.
Es amd64 para servidor en produccion ?
2008/7/7 Alvaro Herrera [EMAIL PROTECTED]: Aldrin Martoq escribió: Por lo tanto, lo que digo es que no deberiamos tener distros 64bits y otras 32bits; sino que el default debiera ser 32bits y solo las aplicaciones que se beneficien tengan la opcion 64bits. Huh ... ¿qué sentido tendría esto? ¿Desaprovechar totalmente las características de la arquitectura? Si el kernel es de 64 bits, puede aprovechar el mayor direccionamiento de memoria, etc. Esto es importante porque puede usar la memoria extra para cache; de lo contrario tiene que usar PAE lo cual tiene un costo de rendimiento no trivial. No todo es ganancia en 64bits. Dudo que firefox necesite mas de 3GB de RAM y/o punteros o calculos grandes. Y pierdes en el cache L1/L2. Entonces, el punto es que debiera ser todo 32-bits por default y solo algunas aplicaciones que lo requieran la opcion de 64 bits. Si el sistema viene con las bibliotecas de 64 bits y las de 32, entonces puedes correr una aplicacion con cualquiera de los dos -- lo único que importa es que el linker sea capaz de ubicar las correctas (ld.so sabe hacerlo, y por eso casi todas las distros soportan esta configuración). Ese es el problema, reemplazaron todo lo que estaba en /lib es 64 bits y hay que instalar ia32-libs ... el default debiera ser al reves, /lib es 32 bits y /lib-64 64bits o algo por el estilo. Las aplicaciones lo mismo, que sentido tener bash 64bits? etc... La ventaja de un esquema asi puede ir desde la compatibilidad hasta el tuning. Si firefox viniera por default en 32bits no existirian los problemas de compatibilidad con los plugins externos. Si necesitas un postgresql de 64 bits lo podrias correr, pero no es necesario que el resto del sistema corra full a 64bits con la carga extra en memoria que eso conlleva. ffmpeg sí tiene código ASM optimizado por arquitecturas, puedes mirarlo acá: http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/ No veo a simple vista nada con amd64 o parecidos! -- Aldrin Martoq http://aldrinvideopodcast.podshow.com/
Es amd64 para servidor en produccion ?
Aldrin Martoq escribió: 2008/7/7 Alvaro Herrera [EMAIL PROTECTED]: Aldrin Martoq escribió: Por lo tanto, lo que digo es que no deberiamos tener distros 64bits y otras 32bits; sino que el default debiera ser 32bits y solo las aplicaciones que se beneficien tengan la opcion 64bits. Huh ... ¿qué sentido tendría esto? ¿Desaprovechar totalmente las características de la arquitectura? Si el kernel es de 64 bits, puede aprovechar el mayor direccionamiento de memoria, etc. Esto es importante porque puede usar la memoria extra para cache; de lo contrario tiene que usar PAE lo cual tiene un costo de rendimiento no trivial. No todo es ganancia en 64bits. Dudo que firefox necesite mas de 3GB de RAM y/o punteros o calculos grandes. Y pierdes en el cache L1/L2. Entonces, el punto es que debiera ser todo 32-bits por default y solo algunas aplicaciones que lo requieran la opcion de 64 bits. Firefox no necesita mas de 3 GB? Creo que los desarrolladores estarían en desacuerdo ;-) Mi comentario iba al kernel en todo caso. El kernel tiene que ser de 64 bits: para que pueda aprovechar bien la memoria, usar los tipos mas gordos con un solo registro en lugar de dos (por ej. en el filesystem hay direccionamiento de 48 bits en algunas partes sin no me equivoco), etc. El resto de las cosas, da lo mismo y puedes escoger libremente, pero la ganancia por tener los registros extra facilmente puede ser mayor que la perdida por tener datos mas anchos. Si el sistema viene con las bibliotecas de 64 bits y las de 32, entonces puedes correr una aplicacion con cualquiera de los dos -- lo único que importa es que el linker sea capaz de ubicar las correctas (ld.so sabe hacerlo, y por eso casi todas las distros soportan esta configuración). Ese es el problema, reemplazaron todo lo que estaba en /lib es 64 bits y hay que instalar ia32-libs ... el default debiera ser al reves, /lib es 32 bits y /lib-64 64bits o algo por el estilo. Las aplicaciones lo mismo, que sentido tener bash 64bits? etc... No entiendo lo que dices. Da lo mismo dónde estén las bibliotecas. Lo importante es que el linker las encuentre. Si al compilar Firefox le das las opciones al compilador para que genere un ejecutable de 32 bits, va a funcionar correctamente, sin tener que hacerle nada especial al sistema, sin tener que mover bibliotecas. Ahora, si la distro empaqueta Firefox para amd64 en 64 bits o en 32, ya es otro cuento. La ventaja de un esquema asi puede ir desde la compatibilidad hasta el tuning. Si firefox viniera por default en 32bits no existirian los problemas de compatibilidad con los plugins externos. Si necesitas un postgresql de 64 bits lo podrias correr, pero no es necesario que el resto del sistema corra full a 64bits con la carga extra en memoria que eso conlleva. No he probado que pasa instalando Firefox de 32 bits aca, pero mi impresion es que si instalas los paquetes de las bibliotecas necesarias, deberia funcionar. ffmpeg sí tiene código ASM optimizado por arquitecturas, puedes mirarlo acá: http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/ No veo a simple vista nada con amd64 o parecidos! Hmm, cierto, me confundí entre tener 3Dnow! y amd64 :-) http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/i386/fft_3dn2.c?revision=13098view=markup Pero por ej. en uno de los logs habla de x% mas rapido en amd64 cambiando unas variables de int a long. Ah, otra cosa es que usan el tipo int64_t liberalmente, lo cual es obviamente mucho mas rapido en amd64 que en x86 (en este ultimo hay que meterlo en 2 registros, con lo cual la escasez de registros se vuelve un problema serio) -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 Jude: I wish humans laid eggs Ringlord: Why would you want humans to lay eggs? Jude: So I can eat them From [EMAIL PROTECTED] Tue Jul 8 09:19:33 2008 From: [EMAIL PROTECTED] (Ismael Diaz) Date: Tue Jul 8 09:19:40 2008 Subject: ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1 | ACPI: EC: read timeout, command = 128 In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] 2008/7/7 Aldrin Martoq [EMAIL PROTECTED]: [...] Sorry, me referia a que si con las actualizaciones podias volver a *poner* quiet (en vez de *quitarlo*). No, fue lo primero que probe :( -- Ismael Diaz. From [EMAIL PROTECTED] Tue Jul 8 09:27:17 2008 From: [EMAIL PROTECTED] (Ismael Diaz) Date: Tue Jul 8 09:27:21 2008 Subject: ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1 | ACPI: EC: read timeout, command = 128 In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] 2008/7/7 Aldrin Martoq [EMAIL PROTECTED]: [...] Bien, busque en launchpad y aqui esta el bug report:
Es amd64 para servidor en produccion ?
2008/7/6 Aldrin Martoq [EMAIL PROTECTED]: Como siempre el contexto es importante. La pregunta debe partir/incluir cuales son tus aplicaciones/necesidades, no si 64bits es bueno o no... Que aplicaciones para produccion usaras? que tipo? Hay mejoras en la cantidad de almacenamiento que puedes utilizar; si puedes direccionar (por ejemplo, no tengo cifras acá) 4Tb en disco con 32 bits, con 64 es más. La cantidad de fechas disponibles es superior (no tienes el problema de direccionamiento de fechas con 32 bits entre 1970 y 2037, por ejemplo). Tambien hay mayor cantidad de memoria RAM que puedes utilizar por el direccionamiento en 64 bits, pero como habia mencionado Xavier, a una velocidad menor. Luego de varios threads que leí silenciosamente donde se hizo mención a i386 y amd64 , realmente me pregunto si es amd64 una opción real y segura para produccion. Si quieres ejecutar apache con dos paginas en PHP, es una perdida de plata invertir en AMD64. Tengo varios servidores web , correo , stream's audio y video que actualmente están en 32bits. La consulta es mayormente esa. Tengo estabilidad y mejor rendimiento con 64 bits (amd64) ? Yo no tengo idea porque no he tenido un laptop 64bits para jugar... pero la sensacion que tengo es que estamos un poco atrasados al respecto. Si lo estamos. No aprovechamos toda la potencia de los 64 bits. Y es porque muchos de los dispositivos que usamos aun son de 32 bits. El problema radica en que tenemos solo la opcion de blanco o negro (64bits o 32bits) pero no hay grises. Y eso implica cambiar/usar un kernel distinto, drivers distintos (ej: graficos nvidia), bibliotecas distintas (/lib*) y aplicaciones distintas. Pero si tenemos grises, me suena un poco al funcionamiento de Wine, por ende un programa de 32 bits ira mas lento que uno de 64. En general hay varias cosas que no funcionan bien. Hace un año intente armar un servidor 64bits virtualizado con Xen y corriendo software IBM y en particular dicho software no funciono... y la distro (debian) tenia varios problemas tambien que eran particulares a esa version. La maquina tenia 16GB RAM y Linux 32bits si soporta mas de 4GB, pero es mas lento... Que software? Yo hice varias maquinas virtuales con software de 32 y 64 bits corriendo encima, en una maquina de 32, y no tuve problema alguno. Yo estoy seguro que en ambientes gigantes (procesos con harto uso de memoria, bases de datos gigantes o algunos procesos) se esta aprovechando bien linux x86-64. Hay algunos calculos que se ejecutan mas rapido en 64bits por ejemplo. Pero de ahi hacia abajo hasta el notebook tuyo el soporte es con varios problemas y baches... Yep, a eso apunto. -- Rodrigo Fuentealba Concepción, Chile
Es amd64 para servidor en produccion ?
[EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Sat, 5 Jul 2008 18:03:36 -0400, Aldrin Martoq [EMAIL PROTECTED] wrote: Como siempre el contexto es importante. La pregunta debe partir/incluir cuales son tus aplicaciones/necesidades, no si 64bits es bueno o no... Que aplicaciones para produccion usaras? que tipo? [mail resumido] Aldrin Martoq http://aldrinvideopodcast.podshow.com/ El escenario es basicamente servidor web y de correo (postfix virtual users , apache2 , postgresql , mysql). Tengo un par de servidores con 500 y 1000 usuarios correspondientemente y he notado alta carga a ratos. Quiero hace upgrade de memoria de 4gb (actual) a 8gb. Y aprovechar de hacer un upgrade de cpu que tiene un p4 3.4 a un quad core con más cache (sé que no es la mejor maquina pero , hasta el momento era suficiente). Quiero ver si haciendo este upgrade será conveniente pasar a 64bits (amd64). Saludos cordiales.
Es amd64 para servidor en produccion ?
On Sun, 6 Jul 2008, Rodrigo Fuentealba wrote: En base a esto, creo que la opinión rezaria algo asi: Si ya tienes maquinas de 32 bits y no tienes planes de cambiarlas mas que por tener tus servidores en 64 bits, es una perdida de plata la inversion. Si tienes que invertir en maquinas, piensa en el desempeño a futuro y elige AMD64. Desde un celeron para arriba, todas las maquinas x86 que puedes comprar en estos momentos son AMD64. Hay alguna arquitectura que explique o implemente lo que dices aca? PowerPC 64, Ultrasparc y x86-64 son todas arquitecturas que pueden ejecutar dos ISAs nativamente, la de 32 bits y la de 64. A eso te refieres? Hasta lo que entiendo de cómo funciona el enlazado a bibliotecas, una aplicacion de 64 bits no puede enlazar a bibliotecas de 32 bits y viceversa. Desde esa limitacion tenemos entonces que vamos a requerir bibliotecas de 32 bits para ejecutar codigo de 32 bits, tanto como necesitamos el stack de bibliotecas de Wine para ejecutar codigo Windows; esa era mi comparacion. Si, necesitas un set de bibliotecas dinamicas de 32 bits. Pero eso no implica que en 32 bits las aplicaciones se ejecuten mas lento. Saludos, Xavier From [EMAIL PROTECTED] Sun Jul 6 18:19:25 2008 From: [EMAIL PROTECTED] (Rodrigo Fuentealba) Date: Sun Jul 6 18:19:35 2008 Subject: Es amd64 para servidor en produccion ? In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xavier Andrade wrote: | On Sun, 6 Jul 2008, Rodrigo Fuentealba wrote: | | Hay alguna arquitectura que explique o implemente lo que dices aca? | | PowerPC 64, Ultrasparc y x86-64 son todas arquitecturas que pueden | ejecutar dos ISAs nativamente, la de 32 bits y la de 64. A eso te refieres? Erré la pregunta, pero ya me respondi: en todos los sistemas operativos de 64 bits es posible ejecutar codigo de 32 bits nativamente. | Si, necesitas un set de bibliotecas dinamicas de 32 bits. Pero eso no | implica que en 32 bits las aplicaciones se ejecuten mas lento. Me queda claro. Gracias por la paciencia. Saludos, Rodrigo. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJIcUTtAAoJEEiHvghVFqnjCqgP/3QyBrnoeSlENvJAU0cufryz K9hc1zjk22LWP3Q392/pDZw1vleD6K57CM2HKCBaIxOjmL+JWvwk8bc1+NGTjEeH NRyVL0v/wOOjZIp51gpy2Y6B81XNqP/xw1lz2QFcHiDnnXjImjcCVVjSGbXjLCeE PxOZQKvExm/PcOny7HUIf5NIficvdc9PiambZIPpDzlVROClymwRYY5ZjDHmC8Jr YgB8j51oagRjo0nomjJfKofThdPeqiXmfUqBaN3KhkK5oTcrHf0serhfuCdiMqJA rWi9mPy7DUAdEqJbnUeSL94IvW6HR9rxttcW7tVuOr5F1q2cKGUckrSyHxOk1Noi kI8boC2c7Z2KatuENIupl6fZDmLJVyhyxJ1fUwLS0Vw62AFRuV8yA06BsSu9Cvda ut93Y6zWNORW945f4UJFT+JlPdI0Mz5rjY1KKt2Guu0uN8CgwXm4/gUFelG0rZfm vlxMLAdA2NzdfNSIiHteNqk+IcE2QezWkpCemvfAuMk7HKwNjbCiDwa5nuxcSSzA RLnwEpUhJj5nJBEndMFX1SbywU+QVst5SWJN0JM3Tt9/GU+i8mpwMFlwaOwGBl6y Nd5iZqU4S8MaS/UCpVSC9OoWYIT+8fgxId2RML+nKCdRN5QyhwnzbyvTq06+rj7l ceSDO9e2uVOmAWgxU5V1 =l14p -END PGP SIGNATURE- From [EMAIL PROTECTED] Sun Jul 6 18:38:43 2008 From: [EMAIL PROTECTED] (Rodrigo Fuentealba) Date: Sun Jul 6 18:38:49 2008 Subject: Es amd64 para servidor en produccion ? In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] El día 6 de julio de 2008 17:54, Hector Gatica [EMAIL PROTECTED] escribió: El escenario es basicamente servidor web y de correo (postfix virtual users , apache2 , postgresql , mysql). Tengo un par de servidores con 500 y 1000 usuarios correspondientemente y he notado alta carga a ratos. Quiero hace upgrade de memoria de 4gb (actual) a 8gb. Y aprovechar de hacer un upgrade de cpu que tiene un p4 3.4 a un quad core con más cache (sé que no es la mejor maquina pero , hasta el momento era suficiente). Eso dependera de tu politica de distribucion de carga entre servidores. Quizas lo que necesitas no es cambiar una maquina completamente para reinstalar todo ahi, sino aislar el servicio mas conflictivo y que tiene mas carga. IMVHO, creo que el servidor correo electronico consume bastantes mas recursos que un servidor Apache, y por ende puedes dejarlo en una maquina aislada exclusiva para eso, distribuyendo un poco las cargas de trabajo. Quiero ver si haciendo este upgrade será conveniente pasar a 64bits (amd64). AMD64 es bien solido. -- Rodrigo Fuentealba Concepción, Chile
Es amd64 para servidor en produccion ?
On Sun, 6 Jul 2008, Hector Gatica wrote: El escenario es basicamente servidor web y de correo (postfix virtual users , apache2 , postgresql , mysql). Tengo un par de servidores con 500 y 1000 usuarios correspondientemente y he notado alta carga a ratos. Quiero hace upgrade de memoria de 4gb (actual) a 8gb. Y aprovechar de hacer un upgrade de cpu que tiene un p4 3.4 a un quad core con más cache (sé que no es la mejor maquina pero , hasta el momento era suficiente). Quiero ver si haciendo este upgrade será conveniente pasar a 64bits (amd64). Con esas cantidades de memoria es mejor que uses 64 bits. Respecto a las aplicaciones, todas esas deberian funcionar sin problemas. Xavier From [EMAIL PROTECTED] Sun Jul 6 21:04:50 2008 From: [EMAIL PROTECTED] (Eduardo Aguila) Date: Sun Jul 6 21:04:56 2008 Subject: Entrevista a Richard Stallman desde Chile In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] El día 5 de julio de 2008 0:59, carlos albornoz [EMAIL PROTECTED] escribió: Eduardo Aguila escribió: Hola, acabo de entrevistar a Stallman (queridos algunos, odiados por otros, lo sé) pero sin duda es un personaje relevante en este mundo, el que quiera hacer criticas o comentarios, puede hacerlo dejando un comentario en la misma noticia o siguiendo este hilo. http://www.tecnologiaslibres.net/2008/06/29/entrevista-a-richard-stallman-desde-chile/ Como dicen por ahí, que siga la musica jajaja. cortita pero buena... felicitaciones. gracias :P -- Eduardo Aguila Tecnología, GNU/Linux, software libre- http://www.tecnologiaslibres.net From [EMAIL PROTECTED] Sun Jul 6 21:08:47 2008 From: [EMAIL PROTECTED] (Eduardo Aguila) Date: Sun Jul 6 21:08:52 2008 Subject: Netiqueta y Mensajes Antiguos [Era: Re: compra de NOTEBOOK] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] [...] Por cierto, el que hace eso es llamado un arqueólogo, porque desentierra un thread... que eres chistoso, joder que me he reido con tus ocurrencias. Yo /no/ recuerdo que ese comportamiento sea mal visto tanto en esta lista como en la etiqueta de inet. -- Eduardo Aguila Tecnología, GNU/Linux, software libre- http://www.tecnologiaslibres.net From [EMAIL PROTECTED] Sun Jul 6 21:10:42 2008 From: [EMAIL PROTECTED] (Eduardo Aguila) Date: Sun Jul 6 21:10:47 2008 Subject: debmirror In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Me interés es ayudarte, no me mal entiendas pero necesitas urgentemente una visita a http://www.sindominio.net/ayuda/preguntas-inteligentes.html http://www.protocolo.org/gest_web/proto_Seccion.pl?rfID=225 -- Eduardo Aguila Tecnología, GNU/Linux, software libre- http://www.tecnologiaslibres.net From [EMAIL PROTECTED] Mon Jul 7 02:53:59 2008 From: [EMAIL PROTECTED] (jose jose) Date: Mon Jul 7 03:14:22 2008 Subject: presentacion Message-ID: [EMAIL PROTECTED] hola, me acabo de apuntar a esta lista de dsitrución linux. me gustaria saber si hay alguna forma de descargar mensajes anteriores al correo y así evitar repetir preguntas que ya se hayan echo anteriormente. saludos a todos los componentes de la lista _ MSN Video. http://video.msn.com/?mkt=es-es From [EMAIL PROTECTED] Mon Jul 7 07:14:48 2008 From: [EMAIL PROTECTED] (Daniel Alex Inostroza Gonzalez) Date: Mon Jul 7 07:15:11 2008 Subject: presentacion In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] jose jose wrote: hola, me acabo de apuntar a esta lista de dsitrución linux. me gustaria saber si hay alguna forma de descargar mensajes anteriores al correo y así evitar repetir preguntas que ya se hayan echo anteriormente. http://listas.inf.utfsm.cl/pipermail/linux/ saludos a todos los componentes de la lista Saludos! -- Daniel Alex Inostroza Gonzalez - counter.li.org #412818 Estudiante de Ingenieria Civil Informatica Universidad Tecnica Federico Santa Maria Valparaiso, Chile From [EMAIL PROTECTED] Mon Jul 7 11:49:31 2008 From: [EMAIL PROTECTED] (jose) Date: Mon Jul 7 11:49:39 2008 Subject: presentacion In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] hola daniel, gracias por la respuesta, pero lo que busco, no se si es posible, es almacenar todos los correos antiguos en un gestor de correo para en caso de tener una duda encontrarlo rápidamente por el asunto, en lugar de bucear por varios años de correos. saludos Date: Mon, 7 Jul 2008 07:14:48 -0400 From: [EMAIL PROTECTED] To: linux@listas.inf.utfsm.cl Subject: Re: presentacion jose jose wrote: hola, me acabo de apuntar a esta lista de dsitrución linux. me gustaria
Es amd64 para servidor en produccion ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hector Gatica wrote: | Amigos listeros : | | Luego de varios threads que leí silenciosamente donde se hizo mención a | i386 y amd64 , realmente me pregunto si es amd64 una opción real y segura | para produccion. Si lo es. Se calienta poquisimo, es un procesador poderoso y si no me crees, tienes a Road Runner, la supercomputadora mas rapida del mundo, basada en amd64 y broadband cell engine de Playstation. | Tengo varios servidores web , correo , stream's audio y video que | actualmente están en 32bits. | | La consulta es mayormente esa. Tengo estabilidad y mejor rendimiento con 64 | bits (amd64) ? - - No es mas estabilidad - - No es mejor rendimiento Lo que ganas con amd64 es capacidad de calculo, lo cual es distinto de rapidez de calculo. En un servidor de bases de datos se podria notar la diferencia. Saludos, - -- Rodrigo Fuentealba Concepción, Región del Bío-Bío, Chile -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJIb5+CAAoJEEiHvghVFqnjCFgP/i62xPxDzosrdszoQCTRGeAR yZ96a7XbNV6SbSWCIvTMj7Z3l8wUEqw7uCJ9rmhQOfbkXGKswwWTqgPlpNlWSQqb QMrNffS5VbqpWrYNoKWsGBFYJE47hy7ArVwPgGFmbUOU30b8KobppoKJZjqZKLsZ Gf7u+7nRnambvf0gUmPtGfLCboRuCpQXavhE5DuWpkjFwwNxOiBNfdGfFq7rSYOy jy+Qi/Xkb5O4MgknOgQ74RBqjuEzA/zE1ZDLFlcahp3+Z0awUQCyZj9RO0oMXDb+ tIGL7E5vlGpG002s2zQxzgFv/R8EFVZWYUJEihFwY9nR4l9/aWiqgnV/wa5aj5bg dKk2lCSzvMqSg5UR11HGxQ6xo5zx0/s8PHCftWp3FErEP74413W74k+4+b5BsTNa fU6+hKqBTFi9tVFNUXtwRiKdOqSiGNmvUUCfSAVYGr/FMMAWMLdijPWfYbfWMWb0 5LCnVJkIypvaIxyiXZmd5EDB7+cHAf7H1GVR+Kp30KbfQV8215DonRho6gS8z+8l tFAkv1s3S+qjUIc5AJsZgo9WV4VBMmeaPOrVy8LyUto9a1l5afc41dEsWoX6U9uD gNOOFFR2HPZ08OCC6uFmFkzTaT1TDeaTQNMpLGGPy9Iol6ewsty0CgKHK/kogl9Y UB8/4mkD72Pe9myuC12r =f/nB -END PGP SIGNATURE- From [EMAIL PROTECTED] Sat Jul 5 16:33:15 2008 From: [EMAIL PROTECTED] (Xavier Andrade) Date: Sat Jul 5 17:19:55 2008 Subject: Es amd64 para servidor en produccion ? In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] On Sat, 5 Jul 2008, Hector Gatica wrote: Amigos listeros : Luego de varios threads que leí silenciosamente donde se hizo mención a i386 y amd64 , realmente me pregunto si es amd64 una opción real y segura para produccion. Tengo varios servidores web , correo , stream's audio y video que actualmente están en 32bits. La consulta es mayormente esa. Tengo estabilidad y mejor rendimiento con 64 bits (amd64) ? En estabilidad deberia ser igual que x86, las distribuciones ya llevan tiempo y son ampliamente usadas en produccion. Respecto a rendimiento, para ese tipo de aplicaciones probablemente el rendimiento sera levemente mas malo en 64 bits, por que tienes que manejar direcciones de memoria mas grandes. Ademas algunos chips (Intel) pueden realizar algunas optimizaciones sobre instrucciones en modo 32 bits y no en modo 64. La unica razon para actualizar es que tus servidores tengan 4 Gb o mas de RAM que es el limite de los 32 bits. Sino, no ganas nada con el cambio y es mejor migrar cuando sea necesario. Saludos, Xavier Andrade From [EMAIL PROTECTED] Sat Jul 5 18:03:36 2008 From: [EMAIL PROTECTED] (Aldrin Martoq) Date: Sat Jul 5 18:29:46 2008 Subject: Es amd64 para servidor en produccion ? In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Como siempre el contexto es importante. La pregunta debe partir/incluir cuales son tus aplicaciones/necesidades, no si 64bits es bueno o no... Que aplicaciones para produccion usaras? que tipo? On Sat, Jul 5, 2008 at 4:33 PM, Xavier Andrade [EMAIL PROTECTED] wrote: On Sat, 5 Jul 2008, Hector Gatica wrote: Luego de varios threads que leí silenciosamente donde se hizo mención a i386 y amd64 , realmente me pregunto si es amd64 una opción real y segura para produccion. Tengo varios servidores web , correo , stream's audio y video que actualmente están en 32bits. La consulta es mayormente esa. Tengo estabilidad y mejor rendimiento con 64 bits (amd64) ? Yo no tengo idea porque no he tenido un laptop 64bits para jugar... pero la sensacion que tengo es que estamos un poco atrasados al respecto. El problema radica en que tenemos solo la opcion de blanco o negro (64bits o 32bits) pero no hay grises. Y eso implica cambiar/usar un kernel distinto, drivers distintos (ej: graficos nvidia), bibliotecas distintas (/lib*) y aplicaciones distintas. En MacOS por ejemplo, el sistema mayoritariamente corre en 32bits (incluso el kernel) pero permite algunas aplicaciones correr a 64bits dando la ventaja de 64bits solo cuando la aplicacion lo requiera y las ventajas de 32bits para el resto de aplicaciones viejas. En estabilidad deberia ser igual que x86, las distribuciones ya llevan tiempo y son ampliamente usadas en produccion. En general hay varias cosas que no funcionan bien. Hace un año intente armar un servidor 64bits virtualizado con Xen y corriendo software IBM y en particular dicho
