Aldrin Martoq escribió:
> On Thu, 2008-07-17 at 12:07 -0400, Daniel Serpell wrote:
>
>> El Wed, Jul 16, 2008 at 07:50:08PM -0400, Felipe Román Márquez escribio:
>>
>>> El 16-07-2008, a las 18:35, Juan Pablo San Martín escribió:
>>>
>>>> ¿Tiene alguien experiencia con usando linux en un Dell Vostro 1000?
>>>> ¿Algún problema con controladores?
>>>>
>> Me parece que el Vostro 1000 no tiene nada que ver con el xps1210,
>> de hecho el Vostro tiene procesador AMD, tarjeta de video Radeon Xpress
>> 1150, pantalla de 15.4", etc.
>> Con respecto a si funcionará en Linux, puedes buscar en google, encontré
>> esto:
>> http://www.linlap.com/wiki/Dell+Vostro+1000
>> Notes
>> The Broadcom based Dell 1390 wireless controller does not function
>> properly yet with the open source drivers available for it so you will
>> need to install ndiswrapper. You can get the required Windows drivers
>> from here.
>>
>
> Me toco ver un dell Vostro hace un mes o algo asi: la broadcom (WiFi)
> fue imposible hecharla andar, no encontramos driver que funcionara con
> ndiswrapper (probamos alrededor de 5-10 y nos aburrimos). Si es posible,
> cambia WiFi por algun chipset basado en Intel.
>
> Del resto funcionaba todo, creo que incluso la webcam.
>
>
Como comentaba, yo en el Vostro 1000 usé el que usa winxp, bajandolo
desde la misma página de Dell.
JPS
From [EMAIL PROTECTED] Thu Jul 17 17:03:17 2008
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Thu Jul 17 17:04:30 2008
Subject: como poner el numero de version en un programa
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Victor Hugo dos Santos <[EMAIL PROTECTED]> wrote:
> se estoy creando un programa, hay alguna regla para poner versiones ???
No...
Pero el nucleo Linux uso el esquema:
x.y.z
x: Rama mayor, se cambia unicamente si hay cambios /muy/ substanciales
(p.ej., 2.0.0 fue la primera version que manejaba mas de una CPU)
y: Version mayor, se cambia cuando hay cambios importantes (particularmente
incompatibles con lo anterior)
z: Version menor, cambios desde la version anterior ("business as usual")
Las versiones estables hoy son x.y.z.w como antes, con w indicando un
conjunto reducido de parches para reparar problemas criticos.
> por ejemplo:
>
> 0.0.1 - titulo del programa
> 0.0.2 - algunas lineas de código
> 0.0.3 - ya funciona en mi maquina
> 0.0.4 - logre hacer que funcione en otra maquina
> 0.0.5 - publique en internet
> 0.1.1 - parches de terceros
> 0.9.9 - beta
> 1.0.0 - final
> el tema es que de la 0.1.1 (o 0.2 / 0.3.3) se salta directamente para
> la 0.9.9 y después 1.0.0 ??
Hay de todo... 0.0.1, luego 0.0.2 (primera publicada), luego 0.18, ...,
para llegar a una interminable serie de 0.99<letra>, 1.0.0, ...
Y los hay quienes simplemente van 1.1.0, ..., 1.1.9, 1.2.0, ... sin cambios
particularmente notables entre 1.1.9 y 1.2.0
Recomendable /no/ incluir letras (confunde a los sistemas como las
versiones de RPM). Posiblemente decir x.y.90, x.y.91, ... antes de
x.(y+1).0 para indicar versiones casi-casi (lo que hace Fedora, los
primeros rc son .90, .91, ...).
> hay algún intinerario ??
> alguna guia que especifique en que versión se deberÃa de iniciar ???
> cuando se deberÃa de saltar de 0.3.1 para 0.4.0 ??
Cuando lo consideres apropiado (o sea, cambios suficientemente fuertes para
justificar 0.3.x a 0.4.x). Y 1.0.0 cuando tengas la primera version
"terminada", lo suficientemente solida para dejarla en manos de "usuarios
finales". Eso si ese esquema es tu idea, aunque los numeros de version
debieran reflejar /algo/ para mi gusto muy particular.
--
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 2340000 Fax: +56 32 2797513
From [EMAIL PROTECTED] Thu Jul 17 17:11:17 2008
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Thu Jul 17 17:12:30 2008
Subject: Es amd64 para servidor en produccion ?
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Hector Gatica <[EMAIL PROTECTED]> 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) ?
Depende de lo que hagas...
Carga "de servidor" en amd64 (y los intel de la misma linea) funciona de lo
mas bien; los "chiches de escritorio" (WiFi, tarjetas de video
"interesantes", ...) no tanto.
--
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 2340000 Fax: +56 32 2797513
From [EMAIL PROTECTED] Thu Jul 17 17:20:38 2008
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Thu Jul 17 17:21:55 2008
Subject: Es amd64 para servidor en produccion ?
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
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?
> 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.
Yo si (hace una semana o asi ;-)
> 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".
Muy raro, eso... en mi Sun tengo un nucleo de 64 bits y la /posibilidad/ de
correr aplicaciones de 64 bits (aunque en SPARC el costo es altisimo, y no
vale la pena mas que por mayor espacio de memoria virtual y algunas cosas
puntuales muy dependientes del nucleo); este laptop es 64 bits casi de
punta a punta, pero con las bibliotecas ad hoc es perfectamente capaz de
correr aplicaciones de 32 bits (y desarrollar tambien, ya que estamos en
eso). Correr aplicaciones de 64 bits sobre un nucleo de 32 me parece muy
complicado (los modelos de tablas de pagina, etc simplemente son
diferentes, y un nucleo programado para 32 no tiene como manejar los
recursos extra de 64 bits).
Ambos ejemplos en ramas de Fedora (Aurora development en SPARC, rawhide aca)
> > 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 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...
Software comercial generalmente esta ajustado a RHEL, y tendra problemas
severos en distribuciones debianitas.
> Creo que tendras que indicarnos que software pretendes usar y si es
> algo alienigena a la distro tendras que hacer un par de pruebas
> (incluso de performance, yo no alcance a llegar a eso).
Definitivamente.
--
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 2340000 Fax: +56 32 2797513
From [EMAIL PROTECTED] Thu Jul 17 17:23:35 2008
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Thu Jul 17 17:24:48 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]>
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 ;-)
--
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 2340000 Fax: +56 32 2797513
From [EMAIL PROTECTED] Thu Jul 17 17:27:53 2008
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Thu Jul 17 17:29:09 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]>
Aldrin Martoq <[EMAIL PROTECTED]> wrote:
> 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.
Yep.
> 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.
Eso es un soberano dolor de muelas de administrar. Mejor elegir lo que anda
mejor a lo ancho, y quedarse tranquilo. En x86_64 hay una ventaja
/substancial/ por tener mas registros; en SPARC hay un enorme costo (dos
instrucciones (no una) cada vez que tonteas con direcciones, instrucciones
mucho mas grandes (y caras de ejecutar en una maquina RISC limitada por
acceso a RAM), ...), asi que...
--
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 2340000 Fax: +56 32 2797513
From [EMAIL PROTECTED] Thu Jul 17 17:38:30 2008
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Thu Jul 17 17:39:41 2008
Subject: Correo
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
[...]
> > 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.
nail es un clon de mail (o mailx).
--
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 2340000 Fax: +56 32 2797513
From [EMAIL PROTECTED] Thu Jul 17 17:42:15 2008
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Thu Jul 17 17:43:29 2008
Subject: DNS bug
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Ricardo Utreras Estrella <[EMAIL PROTECTED]> wrote:
> Marcelo Mujica escribió:
> >> Desde el dia de ayer a traves de diversos foros y blogs se ha hecho
> >> eco sobre problemas que afectan a la mayoria de los servicios DNS.
> >>
> >> El boletin de la US-CERT:
> >> http://www.kb.cert.org/vuls/id/800113
> >>
> >> El dia 8/julio/2008 MS publico:
> >> http://support.microsoft.com/kb/953230
> >>
> >> Redhat para sus versiones "Red Hat Enterprise Linux" 2.1, 3, 4, and
> >> 5 libero parches el mismo dia 8/7/2008:
> >> https://rhn.redhat.com/errata/RHSA-2008-0533.html
> >>
> >> Me parece raro que nadie por estos lares hubiese comentado el hecho.
> > Es un error de la mayoria de las implementaciones DNS
> > Segun Dan Kaminsky (Quien investiga el problema) se estarÃa
> > corrigiendo en forma secreta para luego ditribuir parches en forma
> > coordinada.
> > Mas detalles en http://www.doxpara.com/
> Yep, pero segun tengo entendido los parches actuales lo unico que
> hacen en aleatorizar (¿asi se dice?) el puerto en la comunicacion
> servidor-cliente.
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...
--
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 2340000 Fax: +56 32 2797513
From [EMAIL PROTECTED] Thu Jul 17 17:34:20 2008
From: [EMAIL PROTECTED] (Victor Hugo dos Santos)
Date: Thu Jul 17 18:00:10 2008
Subject: copiando LV entre servidores
Message-ID: <[EMAIL PROTECTED]>
Hola,
que alternativas existen para copiar un Volume Logico desde un
servidor a otro, sin reiniciar ???
hay alguna herramenta que permita exportar en un lado y importar en
otra maquina ??
y que ojala transfiera solo los blocos utilizados, ya que es un volume
de 120GB de los cuales estan siendo utilizado unos 20GB !!!
estaba pensando en hacer utilizar dd para clonar el LV y despues
comprimirlo con gzip... y entonces copiarlo con rsync hacia el
servidor remoto.. pero antes, pense que talvez alguno tenga un mejor
metodo para esta tarea.
SO Linux con LVM2
salu2
--
--
Victor Hugo dos Santos
Linux Counter #224399
From [EMAIL PROTECTED] Thu Jul 17 18:00:51 2008
From: [EMAIL PROTECTED] (Alvaro Herrera)
Date: Thu Jul 17 18:15:29 2008
Subject: DNS bug
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
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...
Por lo que leí, la única implementación que no era vulnerable era djbdns
de Dan Bernstein. 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 :-)
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"La vida es para el que se aventura"
From [EMAIL PROTECTED] Thu Jul 17 18:09:45 2008
From: [EMAIL PROTECTED] (Morenisco)
Date: Thu Jul 17 18:36:32 2008
Subject: copiando LV entre servidores
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On Thu, July 17, 2008 3:34 pm, Victor Hugo dos Santos wrote:
> Hola,
>
> que alternativas existen para copiar un Volume Logico desde un
> servidor a otro, sin reiniciar ???
>
> hay alguna herramenta que permita exportar en un lado y importar en
> otra maquina ??
>
> y que ojala transfiera solo los blocos utilizados, ya que es un volume
> de 120GB de los cuales estan siendo utilizado unos 20GB !!!
Lo que yo haria, seria recrear los mismos VG y LV en la otra maquina
(tamanhos, nombres). Luego de eso, haria una transferencia via rsync.
Ojala te sirva.
Saludos!
--
Morenisco.
Centro de Difusión del Software Libre.
http://www.cdsl.cl
Blog: http://morenisco.belvil.eu
