Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Una opinión sobre el G5

Apple
Por JulHer
departamento mas madera , Sección Tecnología
Puesto a las Sat Jun 28th, 2003 at 10:19:14 PM CET

Soy un recién llegado al mundo de Apple,por lo que no creo ser la persona más indicada para sentar cátedra sobre los nuevos sistemas G5, pero sí me gustaría comentar algunas impresiones sobre los nuevos ordenadores que va a vender Apple.

 


Antes de nada, decir que llevo muchos años usando ordenadores de diferentes arquitecturas, como VAX, Intel, Sparc... y sistemas operativos desde CPM hasta Linux, pasando por VMS, Windows... pero nunca he usado un sistema macintosh. Las "guerras" entre sistemas operativos o arquitecturas me dan completamente igual y no entro en ellas.

Desde hace años, uso únicamente Linux como sistema operativo. La razón es muy simple: cubre todas mis necesidades, que no tienen por qué coincidir con las de nadie, y funciona exactamente igual, o casi, en las dos arquitecturas que uso habitualmente, i386 y Sparc. Otra razón es que después de algún tiempo probando varias distribuciones de Linux encontré una con la me encuentro muy cómodo, Debian. Me resulta fácil de administrar y está portada a un montón de arquitecturas.

También soy de esas personas a las que les gustan "enredar" con el sistema, instalar programas, probar cosas nuevas... y para eso Linux me da una flexibilidad increíble. Puedo modificar hasta el código fuente del núcleo... para los que nos gusta "enredar" es una gozada.

Hace un año, mas o menos, por razones de trabajo, me empecé a interesar por sistemas multiprocesadores, y me encontré con los Power Mac G4 duales. Me llamaron mucho la atención y poco a poco fui leyendo la información que fuí encontrando (mucha) sobre la arquitectura PPC y Linux.

Cuando miro algo nuevo, me interesa mucho la opinión de gente que lo haya usado, y en el caso de usuarios de Linux que lo usaban sobre sistemas macintosh, la opinión que encontré era casi siempre la misma: el hardware era de calidad, y Linux corría muy fino en esas máquinas, aunque había que rascarse el bolsillo. También en esa época inicial de mi acercamiento a macintosh, se comercializó el Cube, un sistema con procesador G4 que no usaba ventiladores, se refrigeraba por convección. Independientemente de que su comercialización tuviera mayor o menor éxito, la idea de un ordenador de esa potencia sin ventilador era, como mínimo, muy buena.

Posteriormente me decidí a comprar un portátil, y ya puestos pues un mac. Justo antes de comprarlo empiezan los rumores... que si nueva gama... que si nuevo procesador de IBM, el PPC970... que si nueva gama de portátiles con un nuevo procesador PPC980... cada día aparecía algo, una foto, una comparativa... y Apple que no abría la boca. Un buen día, aparecieron unas comparativas que decían que esa nueva máquina, ya se le llamaba G5, iba a dejar a los sistemas G4 para labores administrativas y decidí esperar a ver que había de cierto antes de comprar el portátil. Apple seguía sin decir nada pero todo el mundo daba por supuesto que en la WWDC , una conferencia de desarrolladores que iba a tener lugar el 23 de junio, se iban a presentar los nuevos G5. A medida que se iba acercando la fecha de la conferencia, los rumores iban creciendo y con ellos la expectación hasta que por fín llegó el día de la conferencia y se presentaron los nuevos G5. Se hicieron oficiales las características del sistema y se presentaron unas comparativas.

La que se lió. A los dos días había opiniones para todos los gustos... que si era un maquinón, que si las comparativas estaban mal hechas...,en fín, teniendo en cuenta que tanto Intel, AMD y Sun tienen procesadoresde 64 bits que no acaban de despegar, y que hay muchos intereses comerciales en juego, pues se ha levantado una polvareda impresionante. La realidad la sabremos cuando esos sistemas empiecen a llegar a los usuarios y se puedan probar en la realidad.

En frío, las características de la máquina son espectaculares:

  • Procesador PowerPC de IBM de 64 bits: Los sistemas normales de consumo hasta ahora eran de 32 bits (Pentiums y G4). El más lento funciona a 1.6 Ghz y el más rápido a 2 Ghz. IBM ha anunciado que en un año estará escalado a 3 Ghz.
  • Preparado para dos procesadores.
  • Bus de sistema entre 800 Mhz y 1 Ghz. Cada procesador con su propio bus. Recordemos que las memorias actuales de consumo son DDR a 400 Mhz,con lo que ese bus dará mucho juego.
  • Capacidad de hasta 8 GB de memoria DDR.

Y además la máquina viene con salida y entrada óptica de sonido, grabadora de DVD, Firewire 800, salida Gigabit Ethernet, bus AGPx8, discos desde 80 GB, y como opciones 802.11g 54 Mbps (Airport) y Bluetooth.

En fín, un maquinón. ¿Y como se refrigera esto?, pues según Apple, la máquina tiene cuatro zonas térmicas diferenciadas, y en cada una hay un ventilador de baja velocidad, con lo que la máquina es muy silenciosa, aunque esto lo corroborarán los usuarios a medida que vayan recibiendo los G5 y cuenten si parece un reactor o es realmente silencioso.

¿Y que se dice en el mundo linuxero? Pues de todo... en Slashdot hay hilos interminables sobre el nuevo procesador. Hay gente a la que le gusta mucho... para otra gente, más allá del Pentium no hay vida... se dice que IBM sacará estaciones con el mismo procesador, estaciones que correrán el Linux de IBM de manera nativa en PPC970, y sobre todo, que después de que Apple ha puesto en el mercado de consumo máquinas de 64 bits, tanto Intel como AMD van a tener que mover ficha y poner también alguna máquina asequible en la línea del G5. Y no olvidemos que Sun tiene máquinas de 64 bits ya desde hace tiempo (UltraSparc , sin ir más lejos) y también tendrá algo que decir.

Pero lo único real es que... no hay nada real. Estos sistemas no se verán hasta el mes de agosto, y será en ese momento cuando la comunidad empezará a trabajar para portar Linux a esta nueva arquitectura, y veremos qué tal se comportan juntos, máquina y Linux a 64 bits. A nivel comercial ya se ha dado el primer paso, como este anuncio de que Yellow Dog soportará esta nueva arquitectura.

En fín, a ver si se anima esto y por una vez los consumidores nos podemos beneficiar ;-)

< El software libre en Zaragoza (7 comments) | Mandrake en el escritorio (80 comments) >
Enlaces Relacionados
· Slashdot
· Apple
· Debian
· los Power Mac G4 duales
· Cube
· menor
· mac
· rumores...
· labores administrativas
· WWDC
· creciendo
· G5
· comparativas
· Slashdot[2]
· Intel
· AMD
· Sun
· UltraSparc
· anuncio
· Yellow Dog
· More on Apple
· Also by JulHer

Encuesta
¿Conoces las máquinas de Apple?
· Sí, y son muy buenas 23%
· Sí, y son muy caras 19%
· Merece la pena pagar por lo bueno 12%
· Sí, pero no me parecen buenas 2%
· No, pero me gustaría conocerlas 41%
· No, no pienso conocerlas 0%

Votos: 72
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Una opinión sobre el G5 | 44 comentarios (42 temáticos, 2 editoriales, 0 ocultos)
El hardware de Apple (3.00 / 1) (#5)
por svampa a las Sat Jun 28th, 2003 at 12:40:14 PM CET
(Información Usuario)

Tengo entendido que el principal, y casi exclusivo, proveedor de hardware Apple es Apple. Parece que no es una cuestión de popularidad, que los fabricantes de hardware se olviden de Apple, sino que es política de Apple mantener un control absoluto sobre el hardware.

¿Alguien puede confirmarlo?. Nunca he tocado un Apple, pero si es así, no es algo en lo que me apetezca meterme. Ya hay bastantes problemas para obtener especificaciones de drivers en el mundo Intel, que hay mil proveedores, para ponerse a merced del capricho de un único fabricante en Apple.



La cosa son los drivers, como siempre. (3.50 / 2) (#12)
por arivero (rivero at sol unizar es) a las Mon Jun 30th, 2003 at 01:44:49 AM CET
(Información Usuario) http://dftuz.unizar.es/%7Erivero/

Apple espera que el programador no se escaquee y pase por sus librerias, sin caer en picado a llamar directamente al sistema operativo. Eso siempre pone dificultades al hardware que no venga soportado de salida.

[ Padre ]


 
No comprendo (3.00 / 1) (#6)
por JulHer a las Sat Jun 28th, 2003 at 12:52:32 PM CET
(Información Usuario)

Hay un montón de hardware que funciona tanto en intel como en Apple... por ejemplo, mi escaner epson. Linux está portado desde hace años a arquitectura PPC, con lo que cualquier cosa que reconozca linux funcionará tanto en un i386 como en un PPC.

Un saludo

[ Padre ]


Información obsoleta (3.00 / 1) (#9)
por svampa a las Sun Jun 29th, 2003 at 11:32:09 AM CET
(Información Usuario)

Como he dicho, lo que tengo son informaciones algo obsoletas, hace tiempo (4 años o más) un amigo intentó cambiar el disco duro de un Mac, y había que comprarlo a Mac o nada.

Supongo que desde aquello lejanos hay han standarizado la conectividad, PCI, USB, ATA etc..

[ Padre ]


Yo también Linuxeo con un ibook (4.00 / 2) (#15)
por asertus a las Mon Jun 30th, 2003 at 08:21:35 AM CET
(Información Usuario)

De hecho creo que merece la pena a cualquier aficionadillo echarle un vistazo, yo uso gentoo con el ibook, y funciona todo, con su KDE, openoffice, quemador de Cds..., en 2kg de portátil y blanco...., una virguería...

Creo que también es interesante echarle un vistazo a la implementación de las X para el Mac OS que ha hecho apple y, si os va BSD, otro vistazo al kernel..., con un sencillo truco te conviertes en root de tu mac y es tuyo totalmente.., incluso para descuajaringarlo....

Hoy día para el Mac se pueden compilar casi cualquier código fuente para Linux/BSD, incluso se han portado la QT con la misma licencia que para Linux.

http://www.trolltech.com/newsroom/announcements/00000129.html

Y, según Apple, el rendimiento y las aplicaciones 64 bit para el G5 estarán disponibles realmente cuando lo esté el GCC para PowerPC a 64 bit... GCC es ahora el compilador "oficial" de la plataforma hardware.

Siento parecer demasiado exaltado, pero creo que el lanzamiento del G5 es una buenísima noticia para los que pensamos (igual soy yo sólo) que el verdadero monopolio que padecemos o padeceremos será el de la arquitectura Intel como nos descuidemos... (yo quería un clonico con procesador Alpha :-( )...

También, como muchos pensamos, el lanzamiento del G5 será la oportunidad de cazar un G4 DUAL de los de 1.25gh o más a buen precio... :-) ...

Saludos....

[ Padre ]


¿El GCC y Apple? (3.00 / 1) (#16)
por musg0 a las Mon Jun 30th, 2003 at 09:02:26 AM CET
(Información Usuario) http://helvete.escomposlinux.org

Y, según Apple, el rendimiento y las aplicaciones 64 bit para el G5 estarán disponibles realmente cuando lo esté el GCC para PowerPC a 64 bit... GCC es ahora el compilador "oficial" de la plataforma hardware.

¿Quiere decir que Apple meterá mano en el GCC al igual que lo ha hecho en el Khtml para el navegador Safari?

Si es así es una buenísima noticia ya que seguro que avanzará mucho más rápido. Cuando Cygnus y Redhat se metieron en el GCC avanzó mucho en el soporte de optimizaciones de los micros.

[ Padre ]


GCC (4.25 / 4) (#17)
por asertus a las Mon Jun 30th, 2003 at 12:34:39 PM CET
(Información Usuario)

Pues sí, de hecho ya lo hace, gcc es "el compilador" de su sistema operativo basado en BSD Mac OS X. Para compilar C, C++, Objetive C..., es llamado por sus herramientas gratuitas Project Builder e Interface Builder para programar en Mac OS X.

http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/index.html

http://developer.apple.com/tools/index.html

Y una mirada hacia dónde va el OS de Apple:

http://developer.apple.com/unix/index.html

Personalmente le estoy echando un vistazo a la implementación de Java en Apple y la aceleración "hardware" de Swing...

De todas formas, la "licencia" abierta de código de Apple sigue siendo "sospechosa" aunque cada vez de acerca más a BSD.... pero me interesa, como dices, el empuje que da a GCC, y, a partir de ahí, a todo Linux para plataformas distintas del x86....

[ Padre ]


 
gcc + apple (4.00 / 3) (#18)
por ridiculum a las Mon Jun 30th, 2003 at 01:53:32 PM CET
(Información Usuario)

Apple, por lo pronto va a dar soporte para cabeceras precompiladas al GCC, algo que tiene el VC++ desde hace tiempo (aquellos que hayan sufrido con las MFC lo sabran) y el compilador de Borland tambien.

Gracias a la colaboracion de jorginius por darme el enlace sin tener que slashdotear un rato.

Esperemos que las aplicaciones que tiran de C++ tarden menos en compilar.

En un hilo que hubo en la lista de kernel hace poco estuvieron comentando como ha caido la velocidad de compilacion de gcc desde el 2.7, haciendose cada vez mas lento. A ver si a parte de tener un compilador que genere buen codigo tenemos un compilador rapido.

[ Padre ]


 
Antes... (3.00 / 1) (#11)
por pj (postmaster@localhost) a las Sun Jun 29th, 2003 at 10:18:31 PM CET
(Información Usuario) http://blog.mobiplayer.com

Los discos duros eran SCSI, luego IDE y en el G5 son Serial-ATA :-D

[ Padre ]


 
Especificaciones (2.50 / 2) (#10)
por suy (suy21.existe-en.lycos.es) a las Sun Jun 29th, 2003 at 06:04:47 PM CET
(Información Usuario) http://lacurva.net/

Ya hay bastantes problemas para obtener especificaciones de drivers en el mundo Intel, que hay mil proveedores, para ponerse a merced del capricho de un único fabricante en Apple.

Que yo sepa, Apple no da especificaciones de hardware, pero a pesar de eso, en mi ibook funciona todo (acelearación, wireless, sonido, energía...). Hay gente que tiene portátiles a los que instalar y/o configurar según que características, les ha costado una barbaridad más que a mí. ¿Será suerte?.

Aunque lo importante es apostar por hardware del que sí se den especificaciones (ATI, por ejemplo), a veces se dan casos como este.


Esto será mi vida, porque es lo único importante en ella.
Y, si fracaso, moriré, porque para mí no existe nada más.

Raistlin Majere
[ Padre ]


 
No lo creo (3.00 / 1) (#7)
por presi a las Sun Jun 29th, 2003 at 03:14:15 AM CET
(Información Usuario) http://presi.org

funciona exactamente igual, o casi, en las dos arquitecturas que uso habitualmente, i386 y Sparc

Yo uso Linux actualmente en 3 plataformas distintas: PowerPC, Sparc y x86 y la verdad es que la mejor soportada es sin duda x86 mal que me pese, en PowerPC no existen binarios para Flash, ni para máquina virtual Java, ni módulo para trajetas NVidia; en Sparc en concreto el kernel 2.4 no nos funcionaba si no estaba compilado con gcc 2.95 (al menos en la SparcStation 5 que es la que tenemos, un poco vieja, todo sea dicho).



¿por? (3.00 / 1) (#8)
por JulHer a las Sun Jun 29th, 2003 at 11:29:58 AM CET
(Información Usuario)

Hombre, si hay empresas determinadas que sólo preparan _binarios_ para lo que a ellos les viene bien, como flash, nvidia... etc pues allá ellas. Pero yo me refería a que tengo instalado woody en i386 y Sparc y funciona igual, o casi, en ambas arquitecturas.

Y respecto al kernel te diré...

julio@karluvmost:~$ uname -a
Linux karluvmost 2.4.18 #1 jue ago 29 20:31:24 CEST 2002 sparc unknown

y no he tenido ningún problema para compilarlo, eso sí, en woody y con el gcc de la distribución, que para algo lo trae.

Un saludo

[ Padre ]


Debian en Sparc (4.50 / 2) (#25)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 9th, 2003 at 03:44:42 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

A petición de Ridiculum, que no hace más que darme la vara con que tengo que decir algo respecto a Debian y Sparc, escribo este tostón de demasiadas líneas. Por si no no tenéis moral para seguir leyendo, os lo resumo: en Sparc Debian no funciona ni por asomo igual de bien que en x86 (o eso espero, por el bien de los usuarios de Debian en x86 :-)).

tengo instalado woody en i386 y Sparc y funciona igual, o casi, en ambas arquitecturas.

No conozco Debian en x86, pero si me aseguras que funciona igual (o casi) que en Sparc, compadezco a la gente que tiene que sufrirla.

Es bastante frustrante que paquetes de la versión estable (Woody), descargados de los repositorios oficiales, sencillamente no funcionen. Den fallos de segmento nada más al iniciar o errores de "Bus Error" en puntos "aleatorios" (un clásico del código C++ compilado con el gcc-2.95 o 3.0 que se distribuye con Woody bajo Sparcv7 o v8), fallos que pueden ser evitados a veces escogiendo otras opciones de compilación distintas de las que usa Debian por defecto.

Sobre las opciones de compilación: prácticamente toda la distribución (el userland de v9 y todo para v8 y anteriores) se compila para Sparcv7. Para ponernos en situación, Sparcv7 es una arquitectura sobre la que el propio Solaris (versión 8 y posteriores) no corre y no se ha usado para nada salvo para algún sistema embarcable en los últimos 20 años. La "vieja" SS5 de presi ya es una v8.

Lo peor es que la especificación del micro Sparcv7 no incluye fpu ni operaciones "avanzadas" sobre enteros (tan avanzadas como la multiplicación o la división), así que el compilador emite código para emular éstas y las operaciones con reales por software. Huelga mencionar el lamentable desempeño de, por ejemplo, OpenSSL causado por esas opciones de compilación.

En la época de Potato, uno de los responsables de la rama de Debian Sparc mantenía versiones de los paquetes "críticos" compilados para v9 (UltraSparc). Sin embargo, al no ser capaz el sistema de paquetería de Debian de manejar mismas versiones de los mismos paquetes, para la misma arquitectura pero compilados de forma distinta, aquello era un pequeño infierno de mantener y en Woody se ha abandonado esa forma "dual" de distribuir los paquetes. En teoría, la última distribución de Debian que iba a ser compilada para v7 sería Woody, en la práctica seguimos en las mismas con Sid.

Tampoco da una buena impresión que el soporte de Sparcaudio haya sido retirado del kernel de Debian por alguna razón que se me escapa (porque funcionar, en nuestras Sparcs funciona), o que el que se hayan olvidado de incluir en las isos oficiales de Woody un kernel 2.4 de 64 bits para la instalación, cuando la opción en el SILO aparece (estás obligado a arrancar con el de rescate o tirar del 2.2 alternativo) o cosas tan tontas como que el mapa del teclado de las X por defecto no tenga en cuenta la tecla Meta.

Honestamente, la mayoría de las pegas, salvo algunos scripts de postinstalación de paquetes mal escritos, algunos paquetes mal separados o compilados con opciones sin mucha cabeza (si incluyes el cliente de ssh instala además el servidor, cyrus-imapd no está compilado con soporte para cyrus-sasl, etc. Para más señas, consultad el Diario de Ridiculum) se reducen a problemas del compilador que se incluye con Debian, que es bastante buggy compilando para 32 bits en Sparc y esta totalmente roto si hablamos de generar código de 64 bits. De hecho se incluye una versión antediluviana del egcs para compilar exclusivamente los kernel de 64 bits y que falla casi sistemáticamente en todo lo demás.

En general da la impresión en Sparc de que la gente de Debian verifica que compila y empaquetan el software, sin ni siquiera mirar en un poco de detalle si funciona o no. Puedo entender que eso lo hagan en una versión de desarrollo, esperando que la gente notifique los bugs... Pero que lo hagan en la "estable" me parece una tomadura de pelo. Si no tienen medios para verificar que todo lo que distribuyen funciona, que no lo distribuyan o que lo etiqueten como "no testeado". Mi tiempo es limitado y no quiero perderlo intentando inútilmente hacer funcionar algo que está "roto de fábrica", aún cuando lo llamen "estable".

Respecto al kernel, nosotros tenemos en las SS5, en las Classic y en las Ultra el mismo 2.4.20, aparte de OpenBSD y NetBSD. Creo recordar que tuvimos problemas con el 2.4.18, ya que hubo alguna SS5 a la que le instalamos un 2.2 con los parches para ext3. Pero desde que salio el 2.4.20 ni una pega.

Hemos compilado el kernel para las máquinas de 32 bits un par de veces en las Ultra con el gcc-3.2, usando el entorno sparc32, con éxito irregular. Dependiendo de la fase de la luna, unas veces el kernel funciona y otras no: ahora solemos compilar siempre en las SS5 (total, siempre tenemos alguna ociosa por ahí) con el 2.95 y sin novedad hasta ahora, ni en las Classic ni en las SS5.

[ Padre ]


Debian en Sparc (3.50 / 2) (#31)
por JulHer a las Wed Jul 9th, 2003 at 10:20:21 PM CET
(Información Usuario)

Bueno... mi experiencia se reduce a Sparc IPX y a una SS5 que uso habitualmente como ordenador personal. La verdad es que no he tenido ningún problema con ninguna de ellas a la hora de instalar cosas... por ejemplo esto lo escribo desde un mozilla 1.0, el cual no creo que sea trivial de compilar.

No tengo experiencia en máquinas Sparc de 64 bits... ya me gustaría... pero si os sobra una la acepto gustoso :).

Y una cosa... no estoy de acuerdo con el comentario de que ... debian es Dios y woody su profeta... yo lo veo de una manera diferente. Verás... tanto la versión x86 como la Sparc y todas las demás salen gracias al trabajo de voluntarios que hacen lo que pueden... y yo creo que lo hacen muy muy muy bien. Evidentemente hay fallos (tú has señalado unos cuantos), y la única manera de corregirlos es enviando bugs (cosa que seguramente tanto tú como Ridi habéis hecho varias veces), haciéndose desarrollador,traduciendo... participando, en definitiva, en la distribución y ayudando en la medida de lo posible para que salga con la máxima calidad, aunque se quede en utopía. La versión estable de debian tiene como 4000 paquetes... eso es mucho trabajo... y yo honestamente creo que el trabajo que se hace en todas las arquitecturas de Debian es... estupendo, y que nosotros somos los que tenemos la responsabilidad de mejorarlo.

Un saludo

[ Padre ]


Debian en Sparc: las expectativas y la realidad (3.50 / 2) (#32)
por jorginius ("jorginius" en Google Mail) a las Thu Jul 10th, 2003 at 12:01:50 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Bueno... mi experiencia se reduce a Sparc IPX y a una SS5 que uso habitualmente como ordenador personal

Creo que he visto la foto de la machine que tienes en tu web :-). Te debe rebosar la moral por las orejas para usar una SS5 como ordenador personal :-)... Por cierto, tu modelo es bastante distinto de los nuestros. Nuestras SS5 no tienen ningún framebuffer (la consola la sacas por el puerto A) y son más bajitos. ¿Seguro que es una Server?.

por ejemplo esto lo escribo desde un mozilla 1.0, el cual no creo que sea trivial de compilar.

Ya que lo mencionas, Mozilla no es un buen ejemplo de software exigente con el compilador. En realidad se ha invertido mucho esfuerzo para que compilarlo sea trivial (o casi) en múltiples arquitecturas con compiladores a menudo deficientes: si consultas la guía de portabilidad de C++ que siguen los desarrolladores de Mozilla verás que se restringen a un sub-sub-sub conjunto de C++, "de compilación segura".

Y una cosa... no estoy de acuerdo con el comentario de que ... debian es Dios y woody su profeta...

Yo tampoco estoy de acuerdo, pero estoy en desventaja con respecto a los que si la suscriben :-)

tanto la versión x86 como la Sparc y todas las demás salen gracias al trabajo de voluntarios que hacen lo que pueden.

Yo entiendo que son voluntarios y hacen su mejor esfuerzo, pero también entiendo que las cosas o se hacen bien o no se hacen. Si no tienen medios para testear que lo que empaquetan funciona en una arquitectura, que no den soporte para ella o que den oficialmente un soporte limitado a aquellos paquetes que puedan asegurar que no fallan (y que coloquen un "caution" bien grande en el resto).

Estoy predispuesto a subir informes de fallos en una versión de desarrollo, pero cuando escojo una versión estable en lo último que pienso es en perder dos o tres tardes revisándolo todo de arriba a bajo para terminar descubriendo que el error no es mío sino "de Debian" (quien dice "de Debian", dice del compilador que incluye, de cómo se compiló tal o cual paquete o del kernel estándar). Y eso ya me ha pasado más de una vez (y más de diez).

En fin, que cada vez que veo "la publicidad" de que "Debian soporta 10 u 11 arquitecturas" no puedo evitar sentirme timado, aún cuando no hay dinero de por medio y sin saber si realmente otras aquitecturas como ARM, MIPS o PA-RISC están mejor soportadas que Sparc.

Quizás si no nos estuvieran bombardeando los zelotes cada cinco minutos con las bondades de Debian me lo tomaría con más filosofía. Al fin y al cabo es una tarea muy grande y casi utópica, como dices, hacer funcionar los más de 8000 paquetes correctamente en todas las arquitecturas... Pero ahora sólo veo un desviación bastante grande entre lo que me han estado vendiendo en Barrapunto (je) y lo que me dan. No sé si me explico :-).

[ Padre ]


Debian y BP (3.00 / 1) (#33)
por JulHer a las Thu Jul 10th, 2003 at 01:18:19 PM CET
(Información Usuario)

¿Seguro que es una Server?.

Cuando decía SS5 me refería a SparcStation 5... lamento la confusión. Esto... aprovecho para recordar a la audiencia que acepto donaciones... ;-)

Pero ahora sólo veo un desviación bastante grande entre lo que me han estado vendiendo en Barrapunto (je) y lo que me dan. No sé si me explico :-).

Perfectamente. Te explicas perfectamente. Dejé de leer BP en el momento que me empezó a costar trabajo leer los artículos por la gran cantidad de ruido que había... principalmente por los fundamentalistas, que en BP los había en prácticamente cualquier tema... ahora ni idea como está, pero con libertonia tengo de sobra.

Un saludo

[ Padre ]


 
Problemas con Sparc (3.00 / 1) (#26)
por sinner a las Wed Jul 9th, 2003 at 01:22:43 PM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

Hola,

Dices tener innumerabls problemas con Debian en tu Sparc.

¿Has probado otras distribuciones? ¿Existen otras distribuciones?

RedHat tenía una distro para Sparc. Aún me acuerdo de las estaciones Sun y las máquinas Alpha en el laboratorio de QA de RedHat...

Sobre los problemas del compilador... por esas razones, RedHat utilizaba el gcc-2.96, que es mucho mejor que el gcc-2.95 para opciones multiplataforma.

Y en RedHat siempre puedes ponerles apt4rpm :)




Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org
[ Padre ]


Existen otras distribuciones (4.00 / 1) (#30)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 9th, 2003 at 04:52:56 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

¿Has probado otras distribuciones? ¿Existen otras distribuciones?

De Linux para Sparc, como PLD, Gentoo, SuSE, ROCK Linux o recientemente (después de un tiempo de abandono) la propia Mandrake.

Esas son las que dan soporte oficial, después a partir del abandono de la plataforma por parte de Slackware y de RedHat (en la versión 6.2), surgen Splack y el Proyecto Aurora como sustitutos "no oficiales".

Por lo general están mejor soportados los 64 bits que los 32 (por el kernel, por el compilador y por obsolescencia tecnológica, a partes iguales) y por lo general también el soporte que se le da a la rama de Sparc de esas distribuciones está a la zaga del soporte que se le da a la rama x86 (Aurora distribuye isos RedHat 7.3. SuSE isos de la versión 7.3 de su distribución, etc).

Personalmente yo aposté por Splack pero ya sabes lo que ocurre cuando estás en minoría: Debian es dios, Woody es su profeta y que funcione o no es irrelevante (igual que tengan que formatear la maqueta en la que has estado currando dos semanas para instalar Woody)... Aunque para ser justos lo más probable es que con cualquier otra distribución nos hubiéramos encontrado con problemas similares ya que muchos de ellos se derivan del compilador y del kernel (y otros de código mal escrito, que no tiene en cuenta el endianess o el ancho de los enteros, p.ej). En Linux, cuando sales de x86, ya no pisas terreno firme.

Por otro lado, hemos probado NetBSD y OpenBSD. No les hemos dado tantas vueltas ni mirado tan a fondo como Debian (ni en tantas plataformas: tenemos Debian también en los Alpha), pero no parecen dar muchos problemas. El soporte para el hardware es más limitado (olvídate de sonido o de soporte para el framebuffer), pero funcionan como poco igual de bien.

[ Padre ]


Proyecto Aurora (3.00 / 1) (#40)
por sinner a las Tue Jul 15th, 2003 at 12:01:37 AM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

Si mal no me equivoco, el Proyecto Aurora lo lleva Spot, un colega del LUG (y ex-colega de mis tiempos de RedHat).

Tengo entendido que con Aurora la idea era tener la RHL 7.3 (la mejor de las 7.x) para Sparc.

No sé si Spot tiene mucho tiempo libre, pero sí que se que es un tio competente.

¿Aurora funciona? ¿si o no? Por curiosidad lo pregunto.


Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org
[ Padre ]


Sobre Aurora (3.00 / 2) (#43)
por jorginius ("jorginius" en Google Mail) a las Tue Jul 15th, 2003 at 12:21:14 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Para cuando la conocimos, no habían portado aún el instalador de RedHat y sólo tenían un tercio de los paquetes oficiales compilados... Así que, para ver cómo era, instalamos una Splack básica, más la herramienta de paquetería RPM más los paquetes que tuviera Aurora.

Esa maqueta funcionaba pero no tuve tiempo de probarla a fondo y verle los fallos, ya que falleció un día en circustancias aún por aclarar sobreescrita por una Debian Woody.

Después Aurora sacó iso y el programa de instalación, pero ya teníamos casi todo montado con NetBSD y Debian (las Ultras todas con Debian a golpe de rsync). Por probar, nos bajamos la iso e intentamos instalar en una SS5.

La SS5 va un poco corta de todo, de memoria, de micro, de disco, de velocidad del lector de CD y, en principio, no estaba soportada por Aurora: elegimos una instalación personalizada, y el proceso fue más o menos bien hasta en algún punto de la instalación que saltó una excepción de python poco esclarecedora y ahí se quedó.

Supongo que la culpa del fallo la tendrá lo precario del hardware y que fuera la primera versión que sacaban del instalador. Desde entonces, y a pasado un añito, no hemos vuelto a probar.

[ Padre ]


 
Distintas distros en sparc (3.00 / 1) (#28)
por ridiculum a las Wed Jul 9th, 2003 at 02:25:40 PM CET
(Información Usuario)

Red Hat dejo de soportar Sparc en la epoca de la 6.2, así que no es una buena eleccion. De gentoo mejor ni hablamos, no?

Quedarían Mandrake y Suse.Mandrake que yo sepa no tiene version Sparc (si tiene PPC, por ejemplo), y Suse creo que ha hecho lo mismo que Red Hat, ha dejado de soportar Sparc (La ultima Suse que hay en LinuxIso para Sparc es la 7.3).

Como ves, el panorama es un poco feo :)

[ Padre ]


 
Gentoo en sparc (3.00 / 1) (#38)
por pollo a las Fri Jul 11th, 2003 at 02:23:59 PM CET
(Información Usuario)

¿Habeis probado la Gentoo en sparc? , en principio se solucionarian los problemas de optimización de arquitectura que tiene Debian en este momento. A ver si este verano tengo un poco de tiempo y pruebo.

[ Padre ]


Sparc y gentoo (3.00 / 1) (#39)
por JulHer a las Sun Jul 13th, 2003 at 10:53:41 AM CET
(Información Usuario)

Pues lo miré... pero con un disco de 500 MB me temo que no es posible... ¿o me equivoco?

Un saludo

[ Padre ]


El síndrome de Gentoo (3.00 / 1) (#42)
por musg0 a las Tue Jul 15th, 2003 at 09:57:01 AM CET
(Información Usuario) http://helvete.escomposlinux.org

Debido a la compilación sólo la puedes usar en máquinas que por lo grande no necesitarían optimizar la compilación :-)

Supongo que el problema se arreglaría teniendo una máquina potente con un buen disco que sólo sirviera para compilar. Incluso podría ser un PC barato y hacer compilación cruzada.

Quizás sería una buena idea para LILO que tuvieran una "granja" de compilación con la que recompilar Debian para la versión de máquina Sparc que usen y tener un repositorio de apt desde el que instalen. Además serviría de betatesting de paquetes de Debian.

[ Padre ]


Compilando paquetes (3.00 / 1) (#44)
por jorginius ("jorginius" en Google Mail) a las Tue Jul 15th, 2003 at 02:27:42 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Quizás sería una buena idea para LILO que tuvieran una "granja" de compilación con la que recompilar Debian para la versión de máquina Sparc

Recompilar la distribución entera no merece la pena. De momento sólo hemos recompilado algunos paquetes en las Ultra para las Classic y las Server, de 32 bits y que están disponibles en nuestro FTP (no todos: faltan los kernels, por ejemplo).

La granja de compilación de cuatro u ocho SparcClassic, usando distcc o PVMGmake (nos tira más la primera opción), está en la bandeja de pendientes desde tiempo inmemorial. Estos cubitos invitan a apilarlos y a montar clusters (ver estas fotos o ésta otra. Lo que hay a la izquierda de la HP9000 son pilas de Classics).

[ Padre ]


 
No te digo que no (3.50 / 2) (#13)
por presi a las Mon Jun 30th, 2003 at 03:58:29 AM CET
(Información Usuario) http://presi.org

Lo que es funcionar, Linux funciona muy bien en máquinas no-x86, en mi ibook está todo el hardware soportado, incluyendo las características más especiales; pero también digo que hay software que no está disponible mientras que para x86 si lo está, que la culpa la tienen los que producen ese software propietario, estoy de acuerdo, pero no por ello deja de ser un problema.

En merluzo (nuestro Sparc) nosotros tiramos de sid con gcc 3.2, claro, en woody el gcc que viene por defecto es el 2.95 con el cual sí nos funciona el kernel 2.4.20 que tenemos, tendremos que probar con el nuevo gcc 3.3 a ver si con él se zanja el tema.

[ Padre ]


 
El nuevo PowerMac G5 (3.00 / 1) (#14)
por presi a las Mon Jun 30th, 2003 at 04:02:24 AM CET
(Información Usuario) http://presi.org

A mi personalmente se me cae la baba con el nuevo PowerMac G5, probablemente el próximo ordenador que me compre sea uno de estos, ya no es solo que sea más potente que un x86 (y sus sucesores), el tema es que el diseño es mucho mejor, carcasa mejor diseñada, más accesible a los componentes, menos niveles de ruido, menos calor, y todo se debe en parte a una arquitectura limpia, bien diseñada desde el principio, que no necesita mantener una absurda compatibilidad con sus antecesores de hace más de 20 años, como es el caso de los x86 y si el Opteron prospera, esa tónica va a seguir por los siglos de los siglos.



 
64 bits (3.00 / 2) (#19)
por xitai a las Fri Jul 4th, 2003 at 06:17:38 PM CET
(Información Usuario)

Éste es un comentario un poco fuera del tema.
Siempre que oigo o leo sobre procesadores de 64 bits me pongo a pensar en el gigantesco espacio de direccionamiento que tienen. Lo que a su vez me lleva a pensar en que los sistemas operativos actuales no necesitan tanto, por ello creo que es el momento de desarrollar nuevos sistemas operativos que saquen ventaja de ése hecho.
Por ejemplo, un SO que mapee todo el disco duro y secciones de la red en memoria virtual, que no use sistema de ficheros, sino servidores de objetos. O sea, la siguiente generación de sistemas operativos.
¿Alguien se anima?.
Bueno, no hay que empezar de 0.



Los relativos 64 bits (3.00 / 1) (#20)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Sun Jul 6th, 2003 at 10:06:15 PM CET
(Información Usuario) http://speedball.servemp3.com

Desgraciadamente o no, lo de 64 bits es algo relativo en algunos de los nuevos procesadores con dicha etiqueta. Por lo menos los x86-64 (Opteron y Athlon64), ya que si que es cierto que los registros de enteros son de 64 bits, pero el espacio de direccionamiento no es de 64 bits, sino, según creo recordar, de sólo 48 bits.

Lo que no se es en los G5 cual es el espacio de direccionamiento.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


También 48 bits (3.00 / 1) (#21)
por Heimy a las Mon Jul 7th, 2003 at 07:14:37 PM CET
(Información Usuario)

Y es que si te paras a pensarlo, no tiene demasiado sentido direccionar 64 bits de memoria. Con los 48 bits el salto en magnitud es abismal respecto a los 32 bits de ahora, no digamos 64 bits.

Para que te hagas una idea, los equipos G5 de ahora vendrán limitados (si no recuerdo mal) a un máximo de 8GB, pero es que... ¡son equipos de escritorio! 8GB de RAM es más de lo que hace 5 o 6 años cualquiera de nosotros hubiera soñado siquiera tener encima de nuestra mesa.

[ Padre ]


Memoria.. (3.00 / 2) (#22)
por asertus a las Tue Jul 8th, 2003 at 11:48:30 AM CET
(Información Usuario)

Hace 5 o 6 años 8 gb es lo que soñábamos tener no de RAM, sino de disco duro, :-) .

[ Padre ]


2 Gb (none / 0) (#41)
por Envite a las Tue Jul 15th, 2003 at 01:39:46 AM CET
(Información Usuario)

Yo tengo 2 Gb de disco duro! Y eso entre dos discos, uno de 1.4 y el otro de 600Mb. Y compartidos enter MS-DOS, Windows (NT) y Linux.
y...
no es una maquina tan vieja: es un MMX, y rula mu, mu bien.

Que tiempos aquellos en los que habia que saber programar, para meter tu programa en 48Kb...
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire

[ Padre ]


 
direccionamiento (3.00 / 1) (#23)
por xitai a las Tue Jul 8th, 2003 at 08:08:58 PM CET
(Información Usuario)

Con 48 bits puedes direccionar 256 terabytes, que sería muchísimo si fuera memoria física. Pero para algunas aplicaciones (o sistemas operativos) puede ser interesante tener eso (y más) memoria virtual posible.

De hecho, en el G5 tienes 64 bits de dirección efectiva. Es más, si no se hacen ascos a la técnica de los segmentos, tienes 80 bits de dirección efectiva.

Esto da unas posibilidades muy interesantes que sería largo de explicar aquí.

[ Padre ]


Por direccionar... (4.00 / 1) (#24)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 9th, 2003 at 01:38:42 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Con 48 bits puedes direccionar 256 terabytes

Puedes direccionar mucho más si quieres, a costa de complicar la gestión de la memoria. El 8086 es un micro registros de 16 bits y 16 líneas en el bus de direcciones y maneja mucho más que los 64 KB teóricos, direcciona hasta 1 MB (20 bits).

No es lo habitual, claro, pero sobre el papel nada te lo impide.

...Y por completar, sólo añadir que la familia x86, desde el Pentium Pro, direcciona hasta 64 GB de memoria física (a pesar de ser un "micro de 32 bits"), si bien el espacio de direccionamiento por proceso sigue fijo a 4 GB y el espacio de direccionamiento lógico total a 64 TB, por necesidades del guión (tamaño de los registros apuntadores, principalmente).

Aunque es obvio, también comentar que el límite de los 4GB por proceso (que en realidad no son 4 sino 3 ó 2 dependiendo del diseñador del so) se supera recurriendo al multiproceso: un modelo de varios procesos cooperantes que se comunican entre sí mediante una IPC como memoria compartida y que manejan cada uno un pequeño trocito de los datos.

[ Padre ]


Por direccionar, que no quede (3.00 / 1) (#27)
por xitai a las Wed Jul 9th, 2003 at 01:39:03 PM CET
(Información Usuario)

Sí. Con apoyo de hardware externo se puede direccionar más memoria que la que correspondería por el número de líneas del bus de direcciones. Ya hace 20 años, yo direccionaba medio mega con un z80 a base de paginar memoria.

Perdona que te haga una pequeña correción, pero el 8086 tiene 20 líneas en el bus de direcciones lo que le permite direccionar un mega de memoria física sin ayuda de hardware externo. Los registros de direcciones son de 16 bits, pero con la técnica de los segmentos se le añaden 4 bits más al espacio de direccionamiento, lo mismo que en el 386 y siguientes, que con 32 bits y segmentos tenemos 36 bits de dirección efectiva (64GB), para que esto se pueda traducir en direcciones de memoria física se necesitan 36 líneas en el bus de direcciones, que según tú dices se da a partir del Pentium Pro.

En la arquitectura del PowerPC de 64 bits también existen los segmentos, que amplían el espacio de direccionamiento hasta los 80 bits. Claro está que no hay tantas líneas en el bus de direcciones, el número exacto dependerá del modelo. Según la publicidad de Apple, el G5 admite hasta 8GB, lo que necesita un total de 33 bits. No tengo a mano las especificaciones del procesador, pero éste tendrá, con toda seguridad, más líneas de direcciones, algunos rangos estarán reservados para los periféricos y para ampliaciones futuras.

[ Padre ]


Gracias por la corrección (3.00 / 1) (#29)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 9th, 2003 at 02:36:08 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Perdona que te haga una pequeña correción, pero el 8086 tiene 20 líneas en el bus de direcciones lo que le permite direccionar un mega de memoria física sin ayuda de hardware externo

Cierto, diecesies son las líneas que comparte con el bus de datos, y las cuatro bits más altos se utilizan o bien como parte de la dirección o bien para indicar información adicional al hardware de decodificacíon de direcciones.

...con la técnica de los segmentos se le añaden 4 bits más al espacio de direccionamiento, lo mismo que en el 386 y siguientes, que con 32 bits y segmentos tenemos 36 bits de dirección efectiva (64GB),

Y ahora me permitirás que te corrija yo a ti :-):

En realidad, lo mismo no es: el espacio segmentado lógico de un 386 es de 64 TB (46 bits), tal y como podrás comprobar en el datasheet del micro (16K selectores por 4GB de tamaño máximo por segmento).

Cuando hablo de que la familia x86 a partir del Pentium Pro direcciona 64 GB, hablo de que direcciona hasta 64 GB de memoria física. Emite direcciones físicas de 36 bits. Es lo que se conoce como PAE o Physical Address Extension.

[ Padre ]


Ni para tí ni para mí (3.00 / 1) (#34)
por xitai a las Thu Jul 10th, 2003 at 08:55:09 PM CET
(Información Usuario)

Como escribía de memoria de cosas que hace mucho que no manejo, cabía la posibilidad de que estuviera equivocado, así que, siguiendo tu consejo, he buscado en mi biblioteca el manual de referencia del 486 (es lo más avanzado de Intel que llegué a programar a bajo nivel) y comprendí que había cometido el error de extrapolar el funcionamiento de los segmentos del modo real de 16 bits al modo protegido de 32 bits.

Pero tú estás incurriendo en el error de multiplicar los 4GB del los 32 bits por los 16K selectores para obtener un teórico espacio de direccionamiento de 64TB. En realidad cada selector apunta a un descriptor que define un segmento que no puede salirse de los 32 bits de dirección efectiva. Es decir, como máximo 4GB. Eso es así en el 486 al menos.

Lo mismo nos estamos pasando al discutir aquí este tema tan técnico y tan trivial.

[ Padre ]


Los dichosos 64 TB de los Intel (3.00 / 1) (#35)
por jorginius ("jorginius" en Google Mail) a las Thu Jul 10th, 2003 at 09:49:35 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Pero tú estás incurriendo en el error de multiplicar los 4 GB del los 32 bits por los 16K selectores para obtener un teórico espacio de direccionamiento de 64 TB. En realidad cada selector apunta a un descriptor que define un segmento que no puede salirse de los 32 bits de dirección efectiva

A ver, que me parece que uno de los dos se está perdiendo :-).

En el registro selector de segmento (de 16 bits) tienes los primeros 13 como índice de la tabla de descriptores de segmento, lo cual nos da que hay 8k entradas. Como cada proceso puede usar su LDT o la GDT, tenemos en total 16k entradas disponibles (de las cuales 8K son propias del proceso y 8K son globales).

Cada entrada contiene un descriptor. Los descriptores son de 64 bits, 32 bits para indicar la base y 20 bits para indicar el offset, lo que nos daría segmentos de como máximo 1MB (20 bits), pero como el límite puede expresarse en páginas (de 4 KB, es lo que se conoce como segmentacion paginada), tenemos segmentos de hasta 4 GB, y 4 GB por 16 K entradas dan los 64 TB (32 TB serián compartidas por todos los procesos del sistema y 32 TB estan disponibles como espacio virtual de cada proceso).

Eso es así en el 486 al menos.

Lo que te estoy contando es así desde el 386 (486 incluido). El espacio de direccionamiento virtual no cambia del 386 al 486. Lo que es "novedoso" (Pentium Pro, II, III, etc) son los 64 GB de memoria física direccionable.

Otra característica novedosa que se introduce con el Pentium Pro es que los micros Intel a partir de ahí son RISC. Son micros híbridos que leen instrucciones CISC pero que sólo ejecutan instrucciones RISC: hay un paso de traducción previo y a nivel de microarquitectura se pasa de una unidad microprogramada a una cableada. AMD fue pionera en x86 con esta técnica, en sus chips de 5º generación con tecnología RISC86 Intel tuvo algunos problemas al principio: en el Pentium Pro, la traducción era realmente ineficiente para el código de 16 bits, cosa que no ocurria en los micros de AMD.

Sólo lo comento porque la gente sigue asociando CISC con x86 y RISC con Macs o PowerPC. Igual que lo del límite de 4GB físicas, eso ya es algo del pasado.

Lo mismo nos estamos pasando al discutir aquí este tema tan técnico y tan trivial.

Ahora mismo no tengo nada mejor que hacer :-) y sabiendo el tipo de parroquianos que se juntan por estos lares, no creo que a nadie le suene a chino.

[ Padre ]


Seguimos (3.00 / 1) (#36)
por xitai a las Thu Jul 10th, 2003 at 11:03:00 PM CET
(Información Usuario)

In a segmented model of memory organization, the logical address space consists of as many as 16,383 segments of up 4 gigabytes each, or a total as large as 2^46 bytes (64 terabytes). The processor maps this 64 terabyte logical address space onto the physical address space (up to 4 gigabytes) by the address translation mechanism describred in Chapter 5.

(i486 Microprocessor Programmer's Reference Manual, Intel Corporation, 1990, Parágrafo 2.1.2)

Dirección lógica (0-64TB) -> dirección efectiva (0-4BG) -> dirección física (0-2^L)
Donde L es el número de líneas del bus de direcciones.



Respecto a lo que dices de que, interiormente, los pentiums son RISC, es cierto, lo cual demuestra que los RISCs han ganado la partida. Lo que pasa es que las necesidades de compatibilidad hace que se sigan usando las instrucciones CISCs.

Y qué opinas de los procesadores VLIW (Very Large Instruction Word)? ¿Tienen futuro? ¿Está la tecnología de compiladores lo bastante avanzada para ellos?.

Para los que no lo sepan, se trata de agrupar en una palabra de instrucción, muy larga, de tamaño fijo, varias operaciones que se ejecutan en paralelo.

[ Padre ]


Segmentos por todas partes... Y páginas (3.00 / 1) (#37)
por jorginius ("jorginius" en Google Mail) a las Fri Jul 11th, 2003 at 01:56:13 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

(i486 Microprocessor Programmer's Reference Manual, Intel Corporation, 1990, Parágrafo 2.1.2)

Dirección lógica (0-64TB) -> dirección efectiva (0-4BG) -> dirección física (0-2^L) Donde L es el número de líneas del bus de direcciones.


No veo claro si me estás dando la razón o si no soy capaz de ver lo que quieres decir.

Lo que has leído en el manual es cierto. El espacio de direccionamiento virtual es de 64 TB, la dirección efectiva (u offset) es de 20 bits (20 y no 32) que, hablando en páginas, nos da esos 4GB por segmentos y la dirección física en un 486 es de 32 bits, lo que nos permite acceder a 4 GB de memoria física.

Todo correcto... Pero lo que parece que das a entender es que esto último (la dirección física de 32 bits) limita el uso del resto del espacio virtual de alguna forma :-?. Simplemente cuando accedamos a alguna dirección que no esté disponible en memoria principal, el bit de presencia del descriptor estará inactivo (o el bit de una de las páginas del segmento, ya que estamos trabajando con segmentación paginada), saltaría un trap y el SO que trabajase con ese esquema haría lo que tuviera que hacer.

El espacio de 64 TB es un espacio teórico que nadie usará nunca por ineficiente. Implica usar la 16K entradas conjuntas de las tablas de descriptores de segmento, que a 64 bits por descriptor hacen un total de 128 MB: 64 MB por proceso, sólo la LDT. Sin contar con las tablas de páginas, el tamaño y la complejidad de las estructuras que tendría que manejar el kernel para representar un solo proceso o para llevar la contabilidad de la memoria, los algoritmos que manejen aquello, etc.

... Pero que duda cabe de que sobre el papel y con la publicidad en la mano es perfectamente realizable :-).

Por otra parte, sobre los 64 GB:

The processor maps this 64 terabyte logical address space onto the physical address space (up to 4 gigabytes) by the address translation mechanism describred in Chapter 5.

Si cotejas el capítulo 5 de tu manual con el capítulo correspondiente de uno de un Pentium II (p.ej) verás que es diferente. Hay un nivel más de indirección: paginación a 3 niveles (o a 2 pero con páginas de 2 MB) y la dirección física resultante es de 36 bits.

Y qué opinas de los procesadores VLIW (Very Large Instruction Word)? ¿Tienen futuro?

No sabría decirte, es la primera noticia que tengo de ellos :-}. La verdad es que así, en frío y como lo explicas, no veo la ventaja al invento. Se impone una entrada de diario explicando a los legos como yo de qué va el asunto :-).

[ Padre ]


 
Más que un comentario, una consulta (1.00 / 1) (#3)
por juanma a las Sat Jun 28th, 2003 at 09:54:57 AM CET
(Información Usuario)

Yo no tengo ni idea de arquitecturas diferentes a las Intel o a las AMD, y, por supuesto, tampoco me he metido nunca a instalar un linux en un mac.

¿se puede instalar una distro en un G5? ¿cuál?

Gracias



Me respondo a mí mismo. Perdón (2.00 / 1) (#4)
por juanma a las Sat Jun 28th, 2003 at 10:19:11 AM CET
(Información Usuario)

No lei el último párrafo :-(

[ Padre ]


 
Una opinión sobre el G5 | 44 comentarios (42 temáticos, 2 editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda