On Tue, 22 May 2007 14:04:48 -0400 "Horst H. von Brand" <[EMAIL PROTECTED]> wrote:
> Incluso con *BSD du jour tendras muchos mas problemas con hardware que > con Linux. Hace rato que no Doc.... ya pasamos esa hace rato esa fase :-) > Linux tiene /lejos/ el mayor rango de hardware soportado de > todos los sistemas hoy dia Probablemente si.... pero el hardware soportado por FreeBSD es bastante tambien y salvo casos especiales como placas RAID o NIC marcianas, no me han tocado Hw marcianos en que no se pueda instalar un FreeBSD.... > (si, eso incluye a MSFT, Linux hoy aun > maneja muchas cosas que se descontinuaron alla hace mucho). Como ejemplo acabo de instalar un NetBSD-3.1 (ultimo release) sobre una PI-133MHz con 32MB RAM y funciona perfecto, lo que implica que las cosas antidiluvianas aun son soportadas por los BSD.... claro me va a decir que no es un Hw raro.... pero anda sin dramas. Saludos -- Atentamente. Electronica y Unix +------------------------+---------------------------+ | Ricardo Albarracin B. | Electrolinux | |counter.li.org:#238.105 |[EMAIL PROTECTED]@gmail.com| +------------------------+---------------------------+ | http://electrolinux.dyndns.org | | http://electrolinux.dyndns.org/~ricardo/ | +----------------------------------------------------+ From [EMAIL PROTECTED] Tue May 22 15:56:55 2007 From: [EMAIL PROTECTED] (=?iso-8859-1?Q?Jos=E9_Luis_Palacios_Vergara?=) Date: Tue May 22 16:18:59 2007 Subject: Enlaces redundantes con enlaces dedicados diferentes Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAACnY5cAkTlJLr7QqKecU/j4BAHlvJlV+3QVNkMTwtn/[EMAIL PROTECTED]> Estimados Listeros, tengo una consulta respecto a como puedo tener un dos enlaces dedicados con distintos rangos de Ip's para convertirlo en un enlace redundante tanto en la LAN como a nivel de la WAN, para que accesen desde fuera servicios de los dominios ya sean .cl o .com de tal forma que si se cae uno de los enlaces continúe funcionando el otro, sin que los usuarios externos o internos pierdan el acceso a Internet; ¿cual es la mejor opción? implementar un VRRP, ¿cambiar todo el equipamiento a cisco y utilizar HSRP?, hay alguna opción con dynamic DNS, alguien ha tenido alguna experiencia con una implementación de este tipo? que hacer si se cuenta ya con un firewall? Gracias por cualquier recomendación Saludos JOSE LUIS PALACIOS V. From [EMAIL PROTECTED] Tue May 22 19:48:27 2007 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Tue May 22 19:50:18 2007 Subject: =?iso-8859-1?q?Opini=F3n?= General sobre Linux 64bits In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Matias Valdenegro T. escribió: > El Lun 21 May 2007, Alvaro Herrera escribió: > > Horst H. von Brand escribió: > > > Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > > > Ya, pero cuanto es en un UBench corriendo en un sistema nativo de 32 > > > > bits? No me sorprenderia que el chroot tenga su costo en tiempo de > > > > ejecucion (igual no esperaba que fuera un 20%). > > > > > > 0%. Exacto. Te lo doy firmado. > > > > > > chroot(2) lo unico que hace es cambiar un dato en la estructura del > > > proceso, que indica donde esta / en el sistema de archivos. Y lo que > > > hacen a continuacion es tener bibliotecas y demas maquinaria de 32 bits > > > en ese nuevo ambiente, de forma que programas de 32 bits las encuentren. > > > Claro, significa cargar mas leseras en RAM (biblitecas de 64 /y/ 32 > > > bits), lo que tendra su impacto indirecto. > > > > Hay otro efecto: el de usar bibliotecas de 32 bits que no tienen la > > posibilidad de usar las mañas especiales de la arquitectura mejorada > > (mas registros por ejemplo). Eso no puede tener cero costo. > > Eso no es un costo, es mas que la libreria simplemente no aprovecha todas las > gracias de la arquitectura, de hecho precisamente por eso es el benchmark, > comparar que ganas teniendo los registros agregados (r8-r16), Ese es mi punto. Dado que el ejecutable no puede aprovechar todas las gracias de la arquitectura, corre mas lento que uno que si puede. No es un "costo" pero el resultado final es una disminucion de rendimiento. Probablemente marginal (no 20%), que es lo que yo decia arriba. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ Tulio: oh, para qué servirá este boton, Juan Carlos? Policarpo: No, aléjense, no toquen la consola! Juan Carlos: Lo apretaré una y otra vez. From [EMAIL PROTECTED] Tue May 22 20:04:17 2007 From: [EMAIL PROTECTED] (Matias Valdenegro T.) Date: Tue May 22 20:05:28 2007 Subject: =?iso-8859-1?q?Opini=F3n_General_sobre_Linux?= 64bits In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> El Mar 22 May 2007, Alvaro Herrera escribió: > Matias Valdenegro T. escribió: > > El Lun 21 May 2007, Alvaro Herrera escribió: > > > Horst H. von Brand escribió: > > > > Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > > > > Ya, pero cuanto es en un UBench corriendo en un sistema nativo de > > > > > 32 bits? No me sorprenderia que el chroot tenga su costo en tiempo > > > > > de ejecucion (igual no esperaba que fuera un 20%). > > > > > > > > 0%. Exacto. Te lo doy firmado. > > > > > > > > chroot(2) lo unico que hace es cambiar un dato en la estructura del > > > > proceso, que indica donde esta / en el sistema de archivos. Y lo que > > > > hacen a continuacion es tener bibliotecas y demas maquinaria de 32 > > > > bits en ese nuevo ambiente, de forma que programas de 32 bits las > > > > encuentren. Claro, significa cargar mas leseras en RAM (biblitecas de > > > > 64 /y/ 32 bits), lo que tendra su impacto indirecto. > > > > > > Hay otro efecto: el de usar bibliotecas de 32 bits que no tienen la > > > posibilidad de usar las mañas especiales de la arquitectura mejorada > > > (mas registros por ejemplo). Eso no puede tener cero costo. > > > > Eso no es un costo, es mas que la libreria simplemente no aprovecha todas > > las gracias de la arquitectura, de hecho precisamente por eso es el > > benchmark, comparar que ganas teniendo los registros agregados (r8-r16), > > Ese es mi punto. Dado que el ejecutable no puede aprovechar todas las > gracias de la arquitectura, corre mas lento que uno que si puede. No es > un "costo" pero el resultado final es una disminucion de rendimiento. > Probablemente marginal (no 20%), que es lo que yo decia arriba. Eso es solo un resultado de la arquitectura, el modo legacy es asi, no obtienes las mejoras de rendimiento si tu ejecutable es x86, asi de simple, es la gracia de crear la arquitectura AMD64.
