Es amd64 para servidor en produccion ?

[Rodrigo Fuentealba]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aldrin Martoq wrote:
| 2008/7/8 Xavier Andrade <andrade en theory.polytechnique.fr>:
|> 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.

Yo llevo un tiempo usando solamente aplicaciones de 64 bits en mi
equipo; hasta reemplace el plugin de flash por gnash y se me quito la
mala costumbre de ver youtube <-!

Un usuario comun y silvestre no gana nada. Pero para aplicaciones
grandes si.

| [...]
|> 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).

Me parecio entender dos o tres cosas distintas:

Kernel de 32 bits corriendo aplicaciones de 64 bits? La necesidad de
interpretar los 64 bits en dos pasadas no es un poco caro?

Kernel de 64 bits corriendo aplicaciones de 32 bits? La necesidad de
duplicar bibliotecas no es un poco costoso en disco? y se que el espacio
en disco es barato, pero tambien hay mayor posibilidad de corromper la
base de paquetes instalada, mas paquetes que utilizar y por ende mas
ancho de banda desperdiciado.

Detectar que tipo de maquina es, si es capaz de correr un kernel de 64
bits, y correr todo el stack de aplicaciones de 32 bits salvo las que
sean optimizadas para 64 bits. Esto no es tan soñadoramente dificil.

buscar_aplicaciones_64bits seria algo como:
~    seleccionar aplicaciones de 32 y 64 bits.
~    comparar resultados benchmark.
~    instalar las aplicaciones de mejor benchmark.

si (kernel == i386):
~    buscar_aplicaciones_32bits();
si no, y si (kernel == x86_64):
~   a = buscar_aplicaciones_64bits();

| Ademas, el punto central es que las aplicaciones 64bits seran muy, muy
| pocas. Es decir, esta pega esta enfocada solo en las bibliotecas
| basicas y algunas aplicaciones, no en los 30.000 paquetes de debian.



|> 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")

Ya dije que con "la potencia de los 64 bits" me referia a la mayor
capacidad de calculo y manejo de memoria. :/

|> 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.

Asumiendo que habra pocas nuevas maquinas de 32 bits, no creo que sea
imposible mantener una base de datos sqlite con los parametros a revisar
y detectar en momento de instalacion si la maquina es de 32 o 64 bits.

openSUSE lo hace: no permite instalar una distro de 64 bits en un
procesador que es de 32 bits unicamente. Solo que openSUSE no puede
seleccionar un kernel de 32 bits automagicamente, y eso es un error,
porque asusta al usuario normal.

| Como dije, "ni ahi" con las aplicaciones propietarias... mal que mal,
| usamos Linux por ideologia ;)

Puede ser... pero Youtube es entretenido y con gnash no funciona bien. :-(

| El problema es que no se recomienda 64bits porque "no ganas nada" y
| eso si que esta mal.
|

De acuerdo.

Saludos,

Rodrigo Fuentealba.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBAgAGBQJIc8tDAAoJEEiHvghVFqnj1h0P/R5YvXqlfhYPNUWMMcW8h7WT
xNZEcyY8TIxTHMmjHPFvbiHhDXW+Zj95bqUCsQTbg2MHFx1HdYWBC8pfwWsPt1Mt
05608juvUm9175fEGVpAFqZtAqmiRlWmIze0tyYDdpluOylj56rN8q1NbDzdBUOU
AXe/y28p2DUF9pcewgaBraygWAcVjbDaMdBnVHHXY3yBAvHDDsdQn6baPY72zU02
OsBmhD+wNVGwQHaKP99cWu9pQrgAS06h1Z+3R4Z71pzD7lydX1zXIyDTnNSjuek+
mOanqDG4O863bSUOiW70aWf2EdyH8Zh+lWlXS0FZh+KbExC9hu25Tnj/Fipno/GS
UWwY2Bbf7NwqcUm6Jdmsf2Gm0bj4GVSGnIS6Q/eaUH22WHzd83udFh21RZnk1u2S
Na6zy0OGYZH13MACirseOzAYFVCz2cRnoUiWn2nqYcrVonc04161TBca5uc6q5UH
7GnzEXjYzm/Fo0wZJvaKQpQnGzRqJkKP39vrniUJlF19Cjo1BxWYoOMePgfR7OUk
JAoT6gsLXVbr6JlwxH2zZKo1bIPXCYUjnrDWnf4vgrAHZ2Cbqei4Uw9lLqYaamDb
Tq1HeHSdtdd20OPKh2+j+dvc6YPwz0tuyffxxNBmZ7nMbHPUco5Fuu+1uuCjS/ZV
bg0aigfUQDrnEbCrCzIS
=OV+7
-----END PGP SIGNATURE-----