[OT] Buscando Disco SCSI para Sparc (Era [OT]: Regalo Estacion Sun...)

[Rodrigo Fuentealba]

El 3/04/08, Daniel Serpell <dserpell en gmail.com> escribió:
> ¡Hola!

Je:) Daniel siempre comienza sus correos con ¡Hola! ... es como su
sello personal.

>
>  El Thu, Apr 03, 2008 at 05:47:56PM -0400, Aldrin Martoq escribio:
>
> > 2008/4/3 Rodrigo Fuentealba <darkprox en gmail.com>:
>  > > El 2/04/08, Aldrin Martoq <amartoq en dcc.uchile.cl> escribió:
>  > >  ¿Qué especificaciones tenía?
>  >
>  > Es un atari 65XE, 128KiB RAM; conectado por RCA (la salida 'Monitor').
>
> Esos atari tenían un potenciómetro en medio de la placa madre que controla
>  la generación de la señal de color, al moverlo puedes ajustar el "tinte" del
>  video.

Yep. precisamente, tengo uno de esos y tenía el mismo problema.

>  > >  >  Respecto del 10%, mi sensación es que siempre ha sido así en todos los
>  > >  >  tarros que hemos usado e incluso más. Por ejemplo, por qué cuando
>  > >  >  enciendo mi tarro se demora lo mismo que hace 10, 15 años?
>  > >  No quiero elucubrar, no tengo idea de electrónica, pero creo que las
>  > >  BIOS funcionan a la misma velocidad que hace 15 años para leer todos
>  > >  los dispositivos. Si bien antes podíamos conectar puras cosas por ISA
>  > >  y detectarlas era lento, podemos alegar porque ahora tenemos PCI y
>  > >  AGP, PCI-E, SLI y todos esos chiches... Sin embargo aunque los lea más
>  > >  rápido son más cosas que procesar en un tiempo prudente.
>  >
>  > Aún así eso no explica nada... tenemos EFI, tenemos upstart,
>  > suspender/hibernar... pero al menos en linux nada de eso funciona
>  > óptimamente, por distintas razones.
>
>
> Mmm... no es tan terrible, pero es cosa de hacer unos pocos cálculos.
>
>  En mi Atari 800XL, con la cpu a 1.8MHz, podías escribir toda la RAM
>  (64k) en un poco más de 0.3 segudos (210 KBps).
>
>  En mi computador actual, con cpu a 1.5GHz, en escribir toda la RAM
>  (1G) demora 1.7 segundos (630MBps) [1].
>
>  Osea, en puro inicializar la memoria, me domoro más de 5 veces más.
>
>  Por otra parte, aquí mismo lo que más demora en el inicio es la
>  detección de hardware, cosa que no sería necesaria si no contaramos con
>  autodetección de cuanta cosa exista.

Eso es cierto, ATARI no requiere de detectar hardware, porque sabe y
siempre sabrá que tiene a POKEY para generar sonido; al circuito
GTIA/CTIA para generar cálculos matemáticos y no me acuerdo cómo se
llamaban los otros. Como mucho, deberá detectar si hay una o más
disqueteras conectadas.

O sea, tiene lógica que nos demoremos más, si cada vez hay más cosas
enchufadas al equipo.

>  > Bueno, el punto es que tenemos potencia de sobra para hacer cosas
>  > increíbles... que estemos haciendo las cosas "igual" que hace 5 años
>  > es algo "casual".
>
> Al menos en mi caso, no estoy haciendo cosas "igual" que hace 5 años,
>  ahora puedo ver videos HD en mi computador, hace 5 años sólo veía
>  videos a 720x480 :-)

Pero lo que es procesamiento de textos, ¿quién usa generación
automática de cartas? Como mucho usamos el corrector ortográfico de
OpenOffice.org. Hay 20000 mejoras sobre todo software y la mayoría
continúa usándolos como si no existieran. Incorporamos las cosas que
necesitamos cuando alguien nos la muestra como un "truco"; sí y sólo
si éste no significa más de 7 clicks.

En resumen, un desperdicio de programación de "nuevas features para
OpenOffice.org 2.3.0" si con Abiword+Gnumeric (lo que viene en RedHat
6.2 para edición de textos) teníamos todo lo que requeríamos... y sigo
teniendo todo lo que requiero. ¿Para qué usar mi laptop nuevo? ;-)
Prefiero el Sparc, además, se ve más bonito sobre mi escritorio.

>  Y claro, cosas como Youtube y los sitios dinámicos serian impensables
>  hace unos años atrás.

Yep.

>  > No creo, me parece más sano que los dispositivos hablen un lenguaje en
>  > común en vez de embutir el driver en el dispositivo para ciertos
>  > sistemas operativos.

Sin embargo, Microsoft quiere embutir el driver.

http://tcnologic.wordpress.com/2008/03/24/microsoft-patenta-un-revolucionarios-sistema-plugplay/

Es lógico que es mejor que los dispositivos hablen un lenguaje común;
se disminuye la posibilidad de errores de software en la
implementación de estos. Aún así creo que es mejor que este lenguaje
común funcione sobre un firmware (para que los imbéciles que hacen
hardware se queden tranquilos con que no les van a robar su forma de
hacer las cosas), y se simplifique la programación de sistemas
operativos. El software "just works".

>  > Por ejemplo, todos los dispositivos de
>  > almacenamiento USB funcionan automagicamente porque hablan
>  > USB-STORAGE

O sea, todas soportan que se le envíe información por SCSI embutido
dentro del cable USB; gran cosa. Lo mismo IDE.

>  > Lo mismo las cámaras "webcam" usb; si todas hablaran
>  > UVCVIDEO necesitariamos sólo 1 driver (que ya existe).

Yo aún desconozco qué varía entre un driver y otro. Me gustaría
analizar el software de Michael Xhaard.

> Costó mucho llegar a una interfáz estándar para todos
> los dispositivos, con usb-storage simplemente un transporte de los
> mismos comandos SCSI sobre USB.

Ni hablar de las interfaces Wireless...

>  Cada vez que se populariza un nuevo dispositivo, cada fabricante intenta
>  imponer su propio modelo de comunicación, que aprovecha especialmente
>  las características del dispositivo.

Yep, el problema es que aprovecha las características del dispositivo
"en Windows"; y ya vemos que Windows Vista no le saca partido a
nada... sólo consume.

> Así, con las "web-cam", se cambia el formato de imágen, la compresión
> (inicialmente propietaria y de bajo uso de CPU en la cámara) y otras.
> Lleva tiempo para que algo se estandarice.

Había acabado de preguntar qué variaba entre un dispositivo de cámara
web y otro. Muchas gracias :P

-- 
Rodrigo Fuentealba