Manuales que se encuentran en el rpm howto-html-es, si quieres leer estos archivos en tu sistema localmente instalalo asi:
[dalfa@Mandriva2007 ~]$ su Contraseña: [root@Mandriva2007 dalfa]# urpmi howto-html-es
Al instalarlo se guardara en el directorio /usr/share/doc/HOWTO/HTML/es/
Instalación de Oracle 8.0.5 para Linux
Autor: Luis M . Cruz,
lcruzva@clientes.unicaja.es y Angel Carrasco
karrasko@arrakis.esv1.0, 14 de Julio de 1.999
Existen programas cuya instalación es difícil, existen programas cuya configuración es difícil, existen programas cuyo manejo es difícil y existen programas cuya instalación, configuración y manejo es difícil, por ejemplo: ORACLE.
Este Mini-Como tiene una intención especial: ayudar al usuario realizar por sí mismo una instalación de Oracle.
Desde el principio, siempre ha habido programas que han sido más complicados en algún sentido que otro y como en todo siempre hay exageraciones. Oracle es una de las base de datos relacionales más importantes del mundo pero a su vez es el programa que necesita unas condiciones preinstalatorias bastante rebuscadas y añadiéndose a este particular, algún fallo que recoge el script de instalación hace que sea uno de los programas más complicados de los que nos hayamos encontrado.
Hemos intentado desde un principio explicarlo de una forma clara pero si desea hacer un comentario o alguna pregunta por favor no dude en hacerla. Quejas, reclamaciones y todas esas cosillas van a ir a /dev/null.
Este documento es Copyright (C) 1999 de Luis M. Cruz y Angel Carrasco y es OpenContent (Contenido Abierto). Usted puede redistribuirlo y/o modificarlo bajo los términos de la Licencia OpenContent (OPL) versión 1.0, tal y como fue publicada por la OpenContent Organization. Este documento se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA; sin ni siquiera la garantía implícita de COMERCIABILIDAD o CONVENIENCIA PARA UN PROPOSITO PARTICULAR. Vea la Licencia OpenContent para más detalles. Existe una versión disponible en
http://www.opencontent.org/opl.shtml.
El copyright no es para restringir los derechos a nadie, es para garantizar que todo el mundo pueda usarlo y que de paso no me intenten colgar algún muerto si a alguien le falla algo al intentar hacer lo que aquí indico. Como se suele decir en estos casos, a mi me funciona y su caso puede variar.
Esta es la parte principal para que funcione todo. Aquí creará todos los
pilares para que pueda usted instalar Oracle.
En el apartado hardware:
En el apartado software:
Debe editar dos ficheros para configurar los parámetros referentes a la memoria compartida y a las señales. No es imprescindible pero si conveniente para poder tener un buen entorno de trabajo que soporte cargas elevadas. El primero sería /usr/src/linux/include/asm-i386/shmparam.h Ajustaremos:
El segundo sería /usr/src/linux/include/linux/sem.h
Acto seguido recompilará el Kernel del nuevo.
3.3 Crear el usuario y el grupo DBA
El objetivo es crear un usuario, aquí llamado oracle, que actuará de administrador de la Base de datos dentro del grupo de usuarios DBA (Database Administrator).
Para ello tiene dos métodos.
Primer método
[root@root]# groupadd dba [root@root]# useradd oracle -g dba [root@root]# passwd oracle
Segundo método
Cree el usuario de esta forma.
[root@root]# adduser oracle
Edite el fichero /etc/group. En la línea que lea:
oracle:x:[numero]:
Reescríbala así:
dba:x:[numero]:oracle
Cree una serie de subdirectorios. El primero será para la propia instalación de Oracle (/usr/oracle) y los tres siguientes para la instalación de las bases de datos (/u01, /u02 y /u03). Lo recomendable es que estos subdirectorios puedan ser particiones diferentes para aprovechar mejores ventajas tanto a seguridad, etc. Aproveche la ocasión para crear un subdirectorio local para almacenar algunos scripts.
[root@root]# mkdir /usr/oracle [root@root]# mkdir /u01 [root@root]# mkdir /u02 [root@root]# mkdir /u03 [root@root]# mkdir /usr/local/bin
Después de crearlo, le hará pertenecientes al usuario oracle y del grupo dba.
[root@root]# chown -R oracle:dba /usr/oracle [root@root]# chown -R oracle:dba /u01 [root@root]# chown -R oracle:dba /u02 [root@root]# chown -R oracle:dba /u03
3.5 Definición de las variables de entorno
Para empezar asigne una máscara al usuario oracle para asegurarse que los usuarios de grupo y el resto sólo tienen permiso de lectura y ejecución, pero no de escritura.
[root@root]# umask 022 oracle
Añada las demás variables de entorno al fichero profile. Depende un poco si estamos usando bash y otros factores deberá editar /etc profile,/home/oracle/.profile o /home/oracle/.bash_profile.
export ORACLE_BASE=/usr/oracle/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/8.0.5 export ORACLE_SID=ora8 export ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data export PATH=$PATH:$ORACLE_HOME/bin export ORACLE_OWNER=oracle export LD_LIBRARY_PATH=$ORACLE_HOME/lib export ORACLE_TERM=vt220 export TMPDIR=/var/tmp
Procederá a la instalación de Oracle 8.0.5. Para lo cual debe seguir los pasos siguientes:
Ante todo, asegúrese que el subdirectorio de montaje tenga todos los permisos de la siguiente forma:
[root@root]# chmod 777 /cdrom
Ahora móntelo:
[root@root]# mount -t iso9660 /dev/cdrom /cdrom
Pero se dan casos de que debido a la distribución no pueda ejecutar correctamente los programas, para lo cual, recomendamos:
[root@root]# mount /dev/cdrom /cdrom -o exec -t iso9660
Ahora se complican un poco las cosas. Este fichero es imprescindible; debe tener en cuenta que usará el shell sh y que lo buscará en /usr/bin/sh. Por ejemplo, los que usen Debian deberán hacer lo siguiente:
[root@root]# ln -s /bin/sh /usr/bin/sh
Con esto se salvará el primer problema pero resulta que, oratab.sh emplea una variable GROUPS que en el entorno Bash se considera de sólo lectura y no modificable. La solución que nos queda es instalar otro shell como por ejemplo ash. Entoces se ejecutaría de la siguiente forma:
cd /cdrom/orainst [root@root]# ash oratab.sh
Luego edite el fichero y escriba en la parte final.
[root@root]# joe /etc/oratab ORACLE_SID:ORACLE_HOME:Y
Hay otra alternativa a esto y sería crear el fichero y añadir esta línea. Es preferible seguir siempre la linea más cercana al fabricante.
Ahora sólo queda ejecutar orainst para poder instalar el programa. Ya está preparado para casi todo lo que nos va a surgir en la instalación. Debemos hacerlo como usuario oracle:
[root@root]# su oracle [oracle@root]$ cd /cdrom/orainst [oracle@root]$ ./orainst
Problemas que encontramos en orainst
Como todo en nuestras vidas tiene fallos. He aqui los dos más graves:
Oracle Intelligent Agent (problema de enlazamiento de librerías)
Todavía no sé porqué Oracle tiene fijación con ciertas librerias a las cuales les asigna el nombre que quiere y no el que debería. Por lo tanto, tendremos problemas como éste: se busca tcl.so, cuando en realidad la librería se llama tcl8.0.so). La solución es hacer un enlace simbólico de la libreria tcl8.0 que tengamos instalada.
[root@root]# ln -s /usr/lib/tcl8.0.so /usr/lib/tcl.so
Instalación de la documentación
El problema surge porque a nuestro amigo orainst se le olvida crear el subdirectorio final. Haremos lo siguiente.
[root@root]# cd /usr/oracle/app/oracle/product/8.0.5/doc [root@root]# mkdir -p server.805/install [root@root]# find | xargs chown oracle:dba
Por último, y ya como root, vamos a ejecutar root.sh
[root@root]# cd /usr/oracle/app/oracle/product/8.0.5/orainst [root@root]# ./root.sh
Ahora dira que ORACLE_HOME no es válido, simplemente limitese a decir que si a todo y habra finalizado la instalación. Este es el último fallo. A partir de aqui todo deberá funcionar como un reloj.
El INSFLUG forma parte del grupo internacional Linux Documentation Project, encargándose de las traducciones al castellano de los Howtos, así como de la producción de documentos originales en aquellos casos en los que no existe análogo en inglés, centrándose, preferentemente, en documentos breves, como los COMOs y PUFs (Preguntas de Uso Frecuente, las FAQs. :) ), etc. Diríjase a la sede del Insflug para más información al respecto. En ella encontrará siempre las últimas versiones de las traducciones «oficiales»:
Asegúrese de comprobar cuál es la última versión disponible en el Insflug antes de bajar un documento de un servidor réplica. Además, cuenta con un sistema interactivo de gestión de fe de erratas y sugerencias en línea, motor de búsqueda específico, y más servicios en los que estamos trabajando incesantemente. Se proporciona también una lista de los servidores réplica (mirror) del Insflug más cercanos a Vd., e información relativa a otros recursos en castellano.
En http://www.insflug.org/insflug/creditos.php3 cuenta con una detallada relación de las personas que hacen posible tanto esto como las traducciones.
¡Diríjase a http://www.insflug.org/colaboracion/index.php3 si desea unirse a nosotros!. «Cartel» Insflug, cartel@insflug.org.
BogoMIPS mini-COMO
Wim C.A. van Dorst
baron@clifton.hobby.nl
Traducido por Juan Carlos Durán García
jcdg@hotmail.com16-08-1996, traducido el 12-01-1997
Este texto proporciona información sobre BogoMIPS, recopilada de varias fuentes mediante news y correo. Se puede obtener de varios servidores de archivos ftp de Linux en linux/docs/HOWTO/mini/BogoMips. Se publicó un artículo en Linux Journal, en el número de Enero de 1996.
1. Nota del traductor:
2. Qué son los BogoMIPS
3. Cómo estimar los BogoMIPS
4. Variaciones en las marcas de los BogoMIPS
5. Programa independiente BogoMIPS
6. Mensaje de error BogoMIPS ... failed
7. Acerca de las CPUs clónicas (Cyrix, NexGen, etc)
8. Por qué prestar atención a los BogoMIPS
9. Recopilación de marcas de rendimiento
A lo largo de este documento se emplearán indistintamente los términos "marca" e "índice" como traducción de los términos en inglés "rating" e "index", con el significado más aproximado de "valores numéricos que miden cuantitativamente el rendimiento de un sistema".
Por "programa independiente" me referiré a la traducción del término en inglés "standalone program", con el significado de "programa autónomo que se puede ejecutar en cualquier momento", por contraposición a los programas y rutinas que sólo se ejecutan en determinadas circunstancias como por ejemplo durante el arranque del núcleo.
Por "forzado" me referiré a la traducción del término inglés "overclock", con el significado de "forzado a trabajar a una velocidad superior para la que oficialmente fue diseñado". Las notas del traductor estarán en forma de notas al pie de página para distinguirlas del resto del texto, que es traducción lo más fiel posible del original.
Intel 8088/4.77
0.02 BogoMips
De un mensaje de Lars Wirzenius wirzeniu@kruuna.Helsinki.fi del 9 de Septiembre de 1993, explicando qué los BogoMIPS, con información detallada adicional de Wim van Dorst: "MIPS" es la abreviatura de "Millions of Instructions Per Second Millones de Instrucciones Por Segundo". Es una medida de la velocidad de ejecución de un programa. Como la mayoría de tales medidas, frecuentemente se abusa de ella en vez de usarse correctamente (es difícil comparar con justicia MIPS para diferentes tipos de ordenadores). Los BogoMIPS son una invención de Linus. El núcleo (¿o era un controlador de dispositivo?) necesita un bucle de temporización (el tiempo es demasiado corto y/o necesita ser demasiado exacto para poder emplear un método de espera no basado en bucles de retardo), que tiene que ser calibrado con la velocidad de procesador de la máquina. Por lo tanto, el núcleo mide durante la secuencia de arranque cómo de rápido se ejecuta en el ordenador un determinado tipo de bucle de retardo. "Bogo" viene de "bogus", que significa "algo que es engañoso, incorrecto, falso". Por consiguiente, el valor de los BogoMIPS da una cierta indicación acerca de la velocidad del procesador, pero de forma escasamente científica como para ser llamado de otra manera más que "BogoMIPS". Las razones (hay dos) por las cuales se muestra durante el arranque son:
Los BogoMIPS están definidos en /usr/src/linux/init/main.c (un algoritmo simple en C), y la variable correspondiente del núcleo loops_per_sec se usa en varios controladores de dispositivo en las secciones net, scsi y char. Las verdaderas funciones de retardo están en ensamblador, y por lo tanto cada plataforma tiene su propia función en include/asm/delay.h. Esta variable loops_per_sec se usa en varios controladores para los dispositivos char, net y scsi (ver
find /usr/src/linux -name "*.[hcS] -print -exec fgrep
loops_per_sec {} \;
)
De una iniciativa de Ian Jackson ijackson@nyx.cs.du.edu, y Przemek Klosowski, actualizado y corregido en gran parte por Wim van Dorst con arreglo a los datos actuales, según la lista que se muestra a continuación:
Una guía muy aproximada sobre los BogoMIPS podría ser:
Sistema BogoMIPS Comparacion Intel 8088 frecuencia_reloj * (0.004 ± 0.001) 0.02 Intel/AMD 386SX frecuencia_reloj * (0.14 ± 0.01) 0.8 Intel/AMD 386DX frecuencia_reloj * (0.18 ± 0.01) 1 (definición) Motorola 68030 frecuencia_reloj * (0.25 ± 0.005) 1.4 Cyrix/IBM 486 frecuencia_reloj * (0.34 ± 0.065) 1.8 Intel Pentium frecuencia_reloj * (0.40 ± 0.035) 2.2 Intel 486/AMD 5x86 frecuencia_reloj * (0.50 ± 0.01) 2.8 Mips R4000/R4400 frecuencia_reloj * (0.50 ± 0.015) 2.3 Nexgen Nx586 frecuencia_reloj * (0.75 ± 0.010) 4.2 PowerPC 601 frecuencia_reloj * (0.84 ± 0.015) 4.7 Alpha (todos) frecuencia_reloj * (0.99 ± 0.005) 5.5 Intel Pentium Pro frecuencia_reloj * (0.99 ± 0.005) 5.5 Cyrix 5x86/6x86 frecuencia_reloj * (1.00 ± 0.005) 5.6 Mips R4600 frecuencia_reloj * (1.00) 5.6 AMD 5k86 frecuencia_reloj * (2.00 ± 0.010) 11.1 Motorola 68060 frecuencia_reloj * (2.01) 11.2 Motorola 68040 (aun no hay suficientes datos) Sparc (aun no hay suficientes datos)
4. Variaciones en las marcas de los BogoMIPS
De Linus Torvalds torvalds@cc.helsinki.fi, explicando la variación que puede observarse en las marcas de los BogoMIPS, tomado de c.o.l.development comp.os.linux.development, el 28 de Abril de 1994 El bucle de cálculo de los BogoMIPS está cuantificado, así que lo más probable es que siempre se obtenga el mismo valor exacto. Normalmente sólo se obtendrán valores diferentes si la velocidad está justo en el "límite", cuando pequeñas variaciones (tiempos diferentes para los intervalos de interrupción, etc) lo harán saltar entre dos valores.
5. Programa independiente BogoMIPS
De el fichero readme del programa independiente BogoMIPS de Jeff Tranter jeff_tranter@mitel.com:
Estás harto de reiniciar tu sistema para ver a cuántos BogoMIPS va hoy? (...) "BogoMIPS" es un programa independiente que muestra el rendimiento de tu sistema usando una de las medidas más reconocidas mundialmente. Usa el mismo código empleado en el núcleo de Linux durante el arranque, pero se ejecuta como un programa de usuario. (...) La versión 1.3 de BogoMIPS es ahora portable y debería correr en cualquier sistema que soporte un compilador y librerías ANSI C.
Obsérvese que debido a la carga del sistema los valores calculados con el programa independiente pueden ser más bajos que los registrados en la lista incluida más adelante.
Intrínsecamente el programa independiente no puede dar información precisa similar al índice BogoMIPS de la secuencia de arranque, ya que la carga del sistema competirá con este programa cuando es ejecutado por un usuario corriente.
El código del núcleo de Linux en el que se basa se usa sólo en la versión Intel, y se denomina "BogoMIPS clásico". Linux ha sido portado a plataformas hardware realmente diferentes, y por lo tanto se ha tenido que emplear otro código BogoMIPS, que el programa independiente no tiene en cuenta. Por consiguiente los BogoMIPS medidos con la versión portable pueden ser bastante diferentes de los verdaderos BogoMIPS que se muestran durante el arranque.
6. Mensaje de error BogoMIPS ... failed
Sugerido por varias preguntas en la red y correo privado, con ejemplos de Lily lbliao@alumni.caltech.edu y Pierre Frenkiel frenkiel@cdfap2.in2p3.fr, que en Marzo de 1995 preguntaron:
Cuando arranco Linux me sale el mensaje:
Calibrating delay loop.. ok - 23.96 BogoMIPS failed
Dónde y porqué ha fallado el bucle de calibración de retardo?"
No ha fallado. Si hubiera fallado el texto habría sido:
Calibrating delay loop.. failed
Lo que probablemente falló fue un controlador de algún dispositivo que puede que no esté en la máquina. Justo después de calcular el índice BogoMIPS se inician todos los controladores de dispositivos. Primero los dispositivos SCSI, después los dispositivos de red, etc. Cualquier fallo es advertido a su debido tiempo. En particular merece la pena destacar el controlador AHA152x. Otros efectos del fallo de controladores de dispositivos (y no del fallo de los cálculos de BogoMIPS) son cuelgues del sistema, esperas largas y completos bloqueos del sistema.
Desde Linux 1.2 muchos mensajes de error han sido mejorados, por lo tanto conviene actualizarse al menos a la última versión para averiguar qué controlador de dispositivo en particular es el que está fallando.
7. Acerca de las CPUs clónicas (Cyrix, NexGen, etc)
Las CPUs Cyrix tipo 486 necesitan un software que habilite la caché, a veces denominado software BogoBoost. Hay alguno disponible como programa independiente, y alguno como parche para el núcleo: todo desde archivos normales, en lugares obvios. Las CPUs Cyrix 5x86 y 6x86 pueden lograr mejorar drásticamente sus BogoMIPS mediante branch-prediction
Predicción de salto (una opción de la BIOS). Obsérvese que el aumento de rendimiento es marginal. Hay informes de que la predicción de salto no es 100% estable, y pueden aparecer fallos de memoria. Pero siempre se le puede conceder una oportunidad. Las CPUs NexGen 386-enhanced (386 mejorado), marcadas como Nx586 se listan como tipo 386, ya que el hecho de que rindan como máquinas Pentium no es relevante para BogoMIPS.
Las CPUs AMD 486DX5, también denominadas AMD 5x86, son máquinas 486/33 con frecuencia cuadruplicada, y por lo tanto son listadas como tales. Están en la misma línea que el resto de CPUs 486.
8. Por qué prestar atención a los BogoMIPS
Me permitiré añadir que hay sólo dos razones para prestar atención al índice BogoMIPS que se muestra durante el arranque de Linux:
9. Recopilación de marcas de rendimiento
La siguiente tabla proporciona algunas marcas de BogoMIPS remitidos de varios sistemas. Obsérvese que los índices son de la actual secuencia de arranque de Linux, excepto por supuesto las de la sección de Sistemas no basados en Linux.
9.1 Sistemas 386 configurados extraña o defectuosamente
Sistema BogoMIPS Informador 386DX/16 387 sin cache 0.57 H. Peter Anvin <hpa@nwu.edu> 386DX/25 0.82 P Wright <philip.wright@purplet.demon.co.uk> 386DX/25 sin cache 1.03 Mark A. Horton <mahmha@crl.com> 386SX/16 1.5 Stefan Kromer <sk@galaxy.sunflower.sub.org> 386SX/16 1.6 Bill Davidsen <davidsen@tmr.com> 386SX/20 1.87 Paul C. Dulany <pcdulany@wam.umd.edu> 386DX/25(?) 128c 6.03 Chuck Meo <meo@solbourne.com> 386DX/20 13 Ed Runnion <erunnio@hubcap.clemson.edu>
Sistema BogoMIPS Informador 386SX/16 Packard Bell 2.05 <root@Belvedere\%hip-hop.suvl.ca.us> 386SX/16 2.09 David E. Fox <dfox@belvedere.sbay.org> 386SX/16 2.15 W Stevens <wgsteven@math.uwaterloo.co> 386SX/16 2.2 Lech Marcinkowski <puolalm@tekla.fi> 386SX/16 2.23 Andrew Bulhak <acb@yoyo.cc.monash.edu.au> 386SX/16 2.23 Steven M. Gallo <smgallo@cs.buffalo.edu> 386SX/16 2.34 Kevin Burtch <kburtch@pts.mot.com> 386SX/16 turbo 2.38 Andrew Haylett <ajh@gec-mrc.co.uk> 386SX/16 0c 2.43 Adam Clarke <adamc@loose.apana.org.au> 386SX/16 2.49 Waymon <waymon@pacifier.com> 386SX/20 2.7 Alex Strasheim <astrashe@nyx.cs.du.edu> 386SX/20 2.70 J.L. Brothers <brothers@halcyon.com> 386SXL/25 AMD 2.9 Vaughan R. Pratt <pratt@Sunburn.Stanford.EDU> 386SX/25 AMD 0c 3.06 K.J. MacDonald <kenny@festival.ed.ac.uk> 386SX/25 AMD 3.38 Hamish Coleman <hamish@zot.apana.org.au> 386SX/25 0c 3.52 Rogier Wolff <r.e.wolff@et.tudelft.nl> 386SL/25 Intel 3.57 S Harris <harris@teaching.physics.ox.ac.uk> 386SX/25 AMD 3.62 S Harris <harris@teaching.physics.ox.ac.uk> 386SXL/25 AMD 0c 3.71 David E.A. Wilson <david@cs.uow.edu.au> 386SX/33 Intel 4.06 Kenneth J. Hoover <ken@PSUEDVAX.PSU.EDU> 386SX/33 4.71 Alexander Komlik <apkom@l.ukrcom.kherson.ua> 386SX/40 Intel 0c 6.03 Michael Kenyon <u3g12@keele.ac.uk> 386DX/16 2.49 Mike <mike@emgee.demon.co.uk> 386DX/20 Intel 3.0 Malcolm Reeves <reeves@rocky1.usask.cs> 386DX/20 Intel 3.08 Si. Harris <harris@teaching.physics.ox.ac.uk> 386DX/20 Nec Powermate 3.22 David J Dawkins <davidd@isl.co.uk> 386DX/20 Micronics 3.25 M Haardt <u31b3hs@informatik.RWTH-Aachen.DE> 386DX/20 3.67 Joost Helberg <jhelberg@nlsun8.oracle.nl> 386DX/25 3.91 Ian McCloghrie <imcclogh@cs.ucsd.edu> 386DX/25 3.95 Grant Edwards <grante@aquarius.rosemount.com> 386DX/25 0cache 3.96 J.O. Williams <jow@techbase.com> 386DX/25 32cache 4.53 J.M.A. Lahtinen <jmalahti@klaava.Helsinki.FI> 386DX/33 5.86 Tim Lacy <timla@microsoft.com> 386DX/33 64cache 5.99 Lars Wirzenius <wirzeniu@kruuna.Helsinki.FI> 386DX/33 Intel 5.99 Harri Pasanen <hpasanen@cs.hut.fi> 386DX/33 sin 387 6.03 Joel B.Levin <levin@bbn.com> 386DX/33 387 6.03 Peter Bechtold <peter@fns.greenie.muc.de> 386DX/40 6.21 J.L. Brothers <brothers@halcyon.com> 386DX/33 6.46 Dennis Robinson <djrobins@uxa.cso.uiuc.edu> 386DX/33 6.5 Dean Nelson <deannelson@aol.com> 386DX/33 387 256cache 6.65 Wim van Dorst <baron@clifton.hobby.nl> 386DX/33 6.65 Rick Lim <ricklim@opus.freenet.vancouver.bc.ca> 386DX/33 6.7 Craig Hagan <hagan@cih.com> 386DX/40 6.99 Ken Wilcox <wilcox@math.psu.edu> 386DX/40 AMD 7.76 Joe Phillips <rchandra@letter.com> 386DX/40 AMD 7.10 Kerry Person <kperson@plains.NoDak.edu> 386DX/40 7.10 D. Bikram Singh <a336dhal@cdf.toronto.edu> 386DX/40 128cache 7.23 Julian Francis Day <jfd0@aber.ac.uk> 386DX/40 bogoacelerado 7.23 Pat St Jean <stjean@math.enmu.edu> 386DX/40 AMD 128cache 7.23 R.Bergs <rabe@akela.informatik.rwth-aachen.de> 386DX/40 slow DRAM 7.26 John Lockwood <lockwood@pan.vlsi.uiuc.edu> 386DX/40 128c 7.29 Karsten Friese <ftdkafr@ftd.ericsson.se> 386DX/40 7.29 E.C. Garrison <ericg@nickel.ucs.indiana.edu> 386DX/40 7.29 Darin Cowan <cowan@rubicon.org> 386DX/40 7.29 Bonne van Dijk <bonne@cs.utwente.nl> 386DX/40 AMD 7.76 Todd Lindner <tlindner@panix.com> 386DX/40 7.76 Bear Giles <bear@indra.com> 386DX/40 AMD 387 64c 7.91 <wires@gnu.ai.mit.edu> 386DX/40 7.98 Frank Pilhofer <fp@informatik.uni-frankfurt.de> 386DX/40 64c 7.98 Dean Junk <dpjunk@mm.com> 386DX/40 AMD 32c 7.98 Tommy Olsen <tommyo@ifi.uio.no> 386DX/40 AMD 7.98 James Reith <reith@racores.com> 386DX/40 7.98 Aaron T. Baldie <atb@u.washington.edu> 386DX/40 128c 7.98 John Pate <jpate@easynet.co.uk> 386DX/40 7.98 Christian Nelson <cnelson@csugrad.cs.vt.edu> 386DX/40 7.98 Alan Peckham <peckham@drei.enet.dec.com> 386DX/40 8.06 Richard Brown <brown@midget.towson.edu> 386DX/40 8.06 Bill G. Bohling <bs146@tali.uchsc.edu> Nx586/90 NexGen 67.44 <root@wgw.mnsinc.com> Nx586/90 NexGen 67.44 Robert Gehring <rag@cs.tu-berlin.de> Nx586/90 NexGen 67.48 David G. Eckard <dgeckard@eos.ncsu.edu> Nx586/100 NexGen 74.34 Cameron L. Spitzer <cls@truffala.sj.ca.us> Nx586/100 NexGen 256c 74.56 Marius Groenendijk <marius@cray-systems.lu> Nx586/110 NexGen 256c 81.51 Michael J. Micek <mmicek@muddcs.cs.hmc.edu>
9.3 Sistemas 486 configurados extraña o defectuosamente
Sistema BogoMIPS Informador 486DX/33 0c 1.45 Mark Gray <vatavian@gvu1.gatech.edu> 486SL/25 0c 1.95 Paraskevas Evripidou <skevos@seas.smu.edu> 486DLC/40 0c 2.45 S.Schendel <sschend@magnus.acs.ohio-state.edu> 486DX/33 128c 2.94 P.J. Nefkens <p.nefkens@student.utwente.nl> 486DX4/120 AMD 3.04 Andrew Steinbach <stei0113@maroon.tc.umn.edu> 486DX5/133 AMD 3.05 Eric Hagen <ehagen@hawaii.edu> 486DX4/100 Cyrix 3.06 Stuart Harvey <sharvey@primenet.com> 486DX5/133 AMD 3.06 Charles Galpin <chg@severn.wash.inmet.com> 486DX4/100 3.06 Bear Giles <bear@indra.com> 486DX2/80 3.08 Gerald E. Butler <gbutler@phoenix.kent.edu> 486DX4/120 AMD 3.08 Charles Hines <chuck_hines@vnet.ibm.com> 486DX4/66 256c 3.10 Riccardo Capella <mc8508@mclink.it> 486DX4/100 wb-cache 3.10 Paul Close <pdc@sgi.com> 486DX4/120 3.13 Brian Perkins <bperkins@netspace.com> 486DX4/120 AMD 3.15 <eruston@net2.intserv.com> 486DX4/100 3.17 Thomas Sudbrak <sudbrak@borneo.gmd.de> 486SLC2/50 Cyrix 3.30 Colin J. Wynne <cwynne@sage.wlu.edu> 486DX/33 3.61 Marten van de Laan <marten@cs.rug.nl> 486DX/33 sin turbo 3.61 Dimitris Evmorfopoulos <devmorfo@mtu.edu> 486DX4/120 3.74 Brian Wheeler <bdwheele@indiana.edu> 486DX4/120 AMD 3.74 Frank Pilhofer <fp@informatik.uni-frankfurt.de> 486DX4/100 Cyrix 256c 4 Joel Kelso <joel@cs.murdoch.edu.au> 486DX/33 256c noturbo 4.25 Wouter Liefting <wlieftin@cs.vu.nl> 486DX/33 4.66 Mark Gray <vatavian@gvu1.gatech.edu> 486Rx2 Cyrix 25/50 4.85 <cosc19v2@menudo.uh.edu> 486SX/33 sin turbo 5.21 Scott D. Heavner <sdh@fishmonger.nouucp> 486DX2/66 overdrive 5.37 Jeremy Orr <jeremy@careercenter.sfsu.edu> 486DX/33 5.66 Ryan Tucker <rtucker@ttgcitn.com> 486DX2/66 5.88 P.J. Nefkens <p.nefkens@student.utwente.nl> 486DX4/100 5.94 Howard Goldstein <hg@n2wx.ampr.org> 486DX4/100 AMD 5.94 Mr Pink <vince@dallas.demon.co.uk> 486DX4/100 notebook 6.55 Thomas <tom@dirac.physik.uni-konstanz.de> 486DX4/100 notebook 6.55 Hugh McCurdy <hmccurdy@ix.netcom.com> 486SLC Cyrix 7 Pieter Verhaeghe <pive@uia.ac.be> 486SX/33 7.84 Paul Hedderly <prh6@unix.york.ac.uk> 486DLC/40 7.98 Wil Cromer <nwc2@Ra.MsState.Edu> 486DX4/100 11.11 NN <usenet@uxmail.ust.hk> 486DX4/100 11.3 Earl Gooch <egooch@mc.com> 486/66 Cyrix 13.02 Mike Baptiste <baptiste@bnr.ca> 486SLC2/25 14.6 Vaughan R. Pratt <pratt@Sunburn.Stanford.EDU> 486DX2/66 laptop 14.46 Robert Knop <rknop@netcom.com> 486SLC2/66 18.94 <root@avalon.net> 486DX/33 turbo 19.98 C Vetter <cbvetter@informatik.th-darmstadt.de> 486SX-S/33 UMD 0c 20.20 Hynek Med <xmedh02@manes.vse.cz> 486DX4/75 21.5 Theo Scott <rkwtgs@pukrs3.puk.ac.za> 486DX4/75 24.13 Sherman Hsieh <shieh@csua.berkeley.edu> 486DX2/58 26.3 Vassili Leonov <leonov@iedv7.acd.com> 486SX-S/40 UMD 0c 26.63 Hynek Med <xmedh02@manes.vse.cz> 486SX-U5/40 UMC 0c 26.63 Dusan Mihajlovic <zdule@herkules.co.yu> 486DX4/100 forzado 28.67 Theo Scott <rkwtgs@pukrs3.puk.ac.za> 486DX2/80 36 Mark Lee <mlee@heartlab.rri.uwo.ca> 486DX2/80 50.08 Mark Lee <mlee@heartlab.rri.uwo.ca> 486DX4/100 60 Sebastien Dedieu <dedieu@emi.u-bordeaux.fr> 486DX2/100 forzado 60.45 Tony D Shan <tdsst9+@pitt.edu> 486DX5/133 AMD 75.40 Jeff Hyche <jwhyche@scott.net> 486DX5/133 AMD 80.08 NN <guesta@slip-29-7.ots.utexas.edu> 486DX5/133 AMD 87 John Wiggins <jwiggins@comp.uark.edu>
Sistema BogoMIPS Informador 486DLC/33 9.42 Dennis Robinson <djrobins@uxa.cso.uiuc.edu> 486DLC/33 387DX/40 9.47 Denis Solaro <drzob@vectrex.login.qc.ca> 486DLC/33 Cyrix wb 9.5 Matthew Asplund <matt@xenon.cchem.berkely.edu> 486DLC/33 Cyrix 386 11.2 Alex Freed <freed@europa.orion.adobe.com> 486DLC/40 256c 11.33 S.Schendel <sschend@magnus.acs.ohio-state.edu> 486Dx/40 Cyrix 11.73 Malcolm Bremer <malcolm@strw.LeidenUniv.nl> 486DRx2/40 Cyrix 13.10 Christopher Lau <clau@acs.ucalgary.ca> 486DX/33 Cyrix 13.21 M Haardt <u31b3hs@informatik.RWTH-Aachen.DE> 486DLC/40 bogoaceler. 13.21 Harry Pasanen <ps@tekla.fi> 486DLC/40 487 Cyrix 13.21 Ian A. Verschuren <iav@po.CWRU.Edu> 486DCL Cyrix 13.3 Tracer Bullet P.I. <ges@earth.baylor.edu> 486DLC/40 13.31 Adam Frampton <frampton@access2.digex.net> 486DLC/40 13.31 Rick Chow <crc@cacs.usl.edu> 486SLC-S/33 13.51 Brad Pepers <pepersb@cuug.ab.ca> 486DLC/40 no Cxpatch 15.47 Sergei O. Naoumov <serge@envy.astro.unc.edu> 486DLC/40 TI 128c 15.97 Philip K. Roban <phil@seal.micro.umn.edu> 486DLC/40 Cyrix 15.97 Louis J. LaBash <labash@lcjones.aclib.siue.edu> 486DRx2/40 15.99 Christopher Lau <lauc@fusion.cuc.ab.ca> 486DX2/66 IBM no-FF 19 NN <coolefa@pmifeg.com> 486SLC2/66 IBM 64c 18.95 Sujat Jamil <sujat@shasta.ee.umn.edu> 486SLC2/66 IBM 128c 18.95 Sujat Jamil <sujat@shasta.ee.umn.edu> 486SLC2/66 19.02 Harry Mangalam <mangalam@uci.edu> 486SLC/50 19.28 Sion Arrowsmith <sion@bast.demon.co.uk> 486BL3/75 IBM 256c 21.50 Ming S. Chan <ming.chan@canrem.com> 486DX2/66 Cyrix 128c 26.63 Derek Kwan <dkwan@zeus.UWaterloo.ca> 486DX2/66 Cyrix 26.63 Adrian Parker <adrian@willen.demon.co.uk> 486DX2-S/66 256c 26.63 Jean-Marc Wislez <JeanMarc.Wislez@rug.ac.be>
Sistema BogoMIPS Informador 486SX/20 DECpc 9.98 Thomas Pfau <pfau@cnj.digex.com> 486SX/25 12.24 M. Buchenrieder <mibu@scrum.greenie.muc.de> 486SX/25 12.3 Darren McKay <e9bh@unb.ca> 486SX/25 12.42 Mark R. Lindsey <mlindsey@nyx.cs.du.edu> 486DX/25 12.5 Phillip Hardy <phillip@mserve.kiwi.gen.nz> 486SX/25 12.52 Emmanual Emore <emor7672@elan.rowan.edu> 486DX/33 256c 16.33 Eric Kemminan <ekemmina@pms709.ms.ford.com> 486DX/33 16.35 Christopher L. Morrow <cm43@andrew.cmu.edu> 486DX/33 16.43 Rob Janssen <pe1chl@amsat.org> 486DX/33 64cache 16.44 H. Peter Anvin <hpa@nwu.edu> 486DX/33 256c DIY 16.44 Wouter Liefting <wlieftin@cs.vu.nl> 486DX/33 Intel 128c 16.44 Rafal Kustra <g1krakow@cdf.toronto.edu> 486DX/33 16.5 Alex Freed <freed@europa.orion.adobe.com> 486DX/33 16.6 Vaughan R. Pratt <pratt@Sunburn.Stanford.EDU> 486DX/33 sin turbo 16.61 C Vetter <cbvetter@informatik.th-darmstadt.de> 486DX/33 16.61 Jeffrey L. Newbern <jnewbern@athena.mit.edu> 486DX/33 16.61 Giuseppe De Marco <gdemarco@freenet.hut.fi> 486DX/33 16.61 M Heuler <heuler@informatik.uni-wuerzburg.de> 486DX/33 16.61 Frank Lofaro <ftlofaro@unlv.edu> 486DX/33 16.77 Donald Lewis <dlewis@jackson.freenet.org> 486DX/33 16.77 Stephan Boettcher <staphan@alzt.tau.ac.il> 486DX/33 256c 16.77 David Manchester <mustang@tartarus.uwa.edu.au> 486DX/40 19.8 Jose Calhariz <cal@minerva.inesc.pt> 486DX/40 19.91 M Heuler <heuler@informatik.uni-wuerzburg.de> 486DX/40 19.96 David A. Ranch <dranch@ecst.csuchico.edu> 486DX/40 AMD 19.97 M Haardt <u31b3hs@informatik.RWTH-Aachen.DE> 486DX/40 Intel 19.97 Paul van Spronsen <vspr@teppic.sun.ac.za> 486DX/40 19.97 Ulf Tietz <ulf@rio70.bln.sni.de> 486DX/40 19.97 <Eberhard_Moenkeberg@p27.rollo.central.de> 486DX/40 19.97 Zoltan Lajber <lajbi@lajli.gau.hu> 486DX/40 19.97 Wim van Dorst <baron@wiesje.hobby.nl> 486DX/40 AMD 20 Chuck Munro <chuckm@canada.hp.com> 486DX/40 AMD 20.09 Pieter Eendebak <peendebak@bbsw.idn.nl> 486DX/50 24.48 Arnd Gehrmann <arnd@rea> 486DX/50 AMD 24.85 Klaas Hemstra <hst@mh.nl> 486DX/50 DTK 24.85 Randolph Christophers <randyc@lna.oz.au> 486DX/50 24.85 Kevin Lentin <kevinl@bruce.cs.monash.edu.au> 486DX2/50 24.85 Jason Matthew <jmatthew@kn.pacbell.com> 486DX2/50 24.85 Gregory P. Smith <smithgr@cs.colorado.edu> 486DX/50 VLB 24.97 Tom Miller <tvtom@en.com> 486DX/50 24.99 Jeff <css@erols.com> 486DX/50 Intel 256c 24.99 Mike <mike@emgee.demon.co.uk> 486DX/50 25 Robert Herzog <rherzog@rc1.vub.ac.be> 486DX2/50 25 M. Abrahamsson <swmike@uplift.df.lth.se> 486DX2/50 25.0 Christian Holtje <choltje@ux1.cso.uiuc.edu> 486DX2/50 DECpc 25.04 Thomas Pfau <pfau@cnj.digex.com> 486DX2/50 Eisa 25.04 John Willing <willing@cimage.com> 486DX2/50 256c 25.04 Zhou Yanmo <zhou@gauss.math.usf.edu> 486DX/50 25.04 Michael Kress <kress@hal.saar.de> 486DX2/50 25.04 Mats Wikholm <mwikholm@news.abo.fi> 486DX2/50 25.04 Jean C Delepine <delepine@linux.u-picardia.fr> 486DX/50 25.04 Jean C Delepine <delepine@linux.u-picardia.fr> 486DX/50 25.04 Kevin Burtch <kburtch@pts.mot.com> 486DX/50 notebook 25.04 Pierre Frenkiel <frenkiel@cdfap1.in2p3.fr> 486DX/50 25.10 M Heuler <heuler@informatik.uni-wuerzburg.edu> 486DX2/50 25.4 Brian Kennedy <bkenned@hubcap.clemson.edu> 486DX2/66 32 Lee Sau Dan <h9210876@khuxa.hku.hk> 486DX2/66 32.9 Frederick <niles@axp745.gsfc.nasa.gov> 486DX2/66 33 Alec Muffett <alecm@uk-usenet.uk.sun.com> 486DX2/66 33 NN <coolefa@pmifeg.com> 486DX2/66 33 Steve Tinney <sjt@enlil.museum.upenn.edu> 486DX2/66 Intel 33 Chuck Munro <chuckm@canada.hp.com> 486DX2/66 VLB 33.0 Sebastien Dedieu <dedieu@emi.u-bordeaux.fr> 486DX2/66 AMD 33.05 G. Skinner <gskinner@gwsunix1.crystalball.com> 486DX2/66 33.20 Arnd Gehrmann <arnd@rea> 486DX2/66 Intel/PCI 33.22 C. Menke <carsten.menke@post.uni-bielefeld.de> 486DX2/66 33.22 Brian Ricker <gt2327c@prism.gatech.edu> 486DX2/66 33.22 Don Bennett < <don@engr.mun.ca> 486DX2/66 33.22 Robert Heller <heller@cs.umass.edu> 486DX2/66 33.22 Warwick Ward-Cox <wwar@lostlink.alt.za> 486DX2/66 33.22 Chien-An Chen <giant@nwu.edu> 486DX2/66 Eisa/VL 33.22 Serge <sviznyuk@magnus.acs.ohio-state.edu> 486DX2/66 AMD 33.22 Wayne Robinson <wayner@renoir.cftnet.com> 486DX2/66 Intel 33.22 Jim Barber <yeul@marsh.cs.martin.edu.au> 486DX2/66 33.22 Tom Lowery <tlowery@mcs.kent.edu> 486DX2/66 33.27 S Viznyuk <sviznyuk@magnus.acs.ohio-state.edu> 486DX2/66 33.3 Devon Tuck <devon@netcom.com> 486DX2/66 256cache 33.4 H. Peter Anvin <hpa@nwu.edu> 486DX2/66 33.5 Jongyoon Lee <mr2@netcom.com> 486DX2/66 33.5 Petrovsky Alexey <gong@cs.msu.su> 486DX2/66 33.5 Sung Lee <slee2@umbc.edu> 486DX2/66 33.55 Gene McCulley <mcculley@greatwall.cctt.com> 486DX2/66 33.55 W. Zeilinger <wzeil@doradus.ast.univie.ac.at> 486DX2/66 33.55 Donald Lewis <dlewis@jackson.freenet.org> 486DX2/66 33.55 Eric Malkowski <malk@world.std.com> 486DX2/66 0c 33.55 Chris Petit <mystere@ix.net.com> 486DX2/66 33.55 <al-b@minster.york.ac.uk> 486DX2/66 33.55 Jesper de Jong <jesper@cas.et.tudelft.nl> 486DX2/66 33.55 John Paul Morrison <jmorriso@bogomips.com> 486DX2/66 33.55 Arash <ei39594@ios.chalmers.se> 486DX2/66 33.55 Ralph Lewis <rlewis@mail.wsu.edu> 486DX2/66 33.55 Ulisses Alonso Camaro <alonso@bebe.uv.es> 486DX2/66 33.55 Bussmann <bussmann@wolpi.infomatik.uni-bonn.de> 486DX2/66 Intel/PCI 33.55 Louis J. LaBash <labash@lcjones.aclib.siue.edu> 486DX2/66 Intel 33.55 Andrew Tubbiolo <enigma@seds.lpl.arizona.edu> 486DX2/66 33.55 W Fink <werner.fink@physik.uni-stuttgart.de> 486DX2/66 ICL 33.55 Mathias Koerber <mathias@solomon.technet.sg> 486DX2/66 33.55 Bill Pogue <gwp@dithots.dithots.org> 486DX2/66 256c 33.58 Theo Scott <rkwtgs@pukrs3.puk.ac.za> 486DX2/66 33.7 C Triantafillou <triant@pegasus.montcleair.edu> 486DX2/66 256c Intel 33.81 S Harris <harris@teaching.physics.ox.ac.uk> 486DX2/66 33.9 Magnus Back <erambk@eraj.ericsson.se> 486DX2/66 notebook 33.9 Robert A Knop <rknop@mop.caltech.edu> 486DX2/66 34.06 Al Clark <aclark@netcom.com> 486DX4/75 37.47 G Asmundarson <grettir@wordperfect.com> 486DX2/80 39.93 Andrew Tubbiolo <enigma@seds.lpl.arizona.edu> 486DX2/80 forzado/66 39.94 Mario L. Guttierez <mgutier@mentor.sdu.edu> 486DX2/80 AMD 39.94 Corey D Brenner <brenner@umr.edu> 486DX2/80 39.94 Dan Delaney <cgdela01@homer.louisville.edu> 486DX2/80 39.94 D t Haar <danny@caution.cistron.nl.mugnet.org> 486DX2/80 forzado 39.94 Peter Suetterlin <ps@kis.uni-freiburg.de> 486DX2/80 AMD 39.94 JL Gomez <kitana!sysop@caprica.com> 486DX2/80 AMD 39.94 Pete Krawczyk <pkrawczy@uiuc.edu> 486DX2/80 AMD 40 Rene Baart <baart@simplex.nl> 486DX2/80 AMD 40 Wolfgang Kalthoff <wo@rio70.bln.sni.de> 486DX2/80 40.0 Rick Brown <ccastrb@prism.gatech.edu> 486DX2/80 AMD 40.14 Jon Lewis <jlewis@inorganic5.chem.ufl.edu> 486DX2/80 AMD 40.14 Richard S. Stone <rstone@edgp.com> 486DX2/80 40.15 Oleg <oleg@hpcms.co.il> 486DX2/80 AMD 40.18 Adri Verhoef <a3@a3.xs4all.nl> 486DX2/80 40.18 Mats Andtbacka <mandtback@abo.fi> 486DX2/100 AMD forza. 49.14 Jon Lewis <jlewis@inorganic5.chem.ufl.edu> 486DX4/100 256c 49.71 Lutz Pressler <lutz.pressler@med-stat.GWDG.de> 486DX4/100 49.71 Brett Gersekowski <bgrerseko@powerup.com.au> 486DX4/100 Intel 256c 49.77 Angelo Haritsis <ah@doc.ic.ac.uk> 486DX4/100 49.78 Aurel Balmosan <aurel@xylo.owl.de> 486DX4/100 49.87 Chris Saia <minkie@concentric.net> 486DX4/100 50 Donald Lewis <dlewis@jackson.freenet.org> 486DX4/100 50.02 Peter Skov Knudsen <gogol@ask.diku.dk> 486DX4/100 50.02 Shadow Weaver <djamison@students.wisc.edu> 486DX4/100 AMD 50.3 Dave <shodan@shodan.clark.net> 486DX4/100 AMD 50.04 Tony Smolar <asmolar@fast.net> 486DX4/100 50.05 fredk <fredk@shadow.net> 486DX4/100 50.06 Ronald Prague <ronp@fisnet.net> 486DX4/100 50.08 Matt Gisher <matt@matt.fidalgo.net> 486DX4/100 50.08 Steven A. Duchene <sduchene@cis.ysu.edu> 486DX4/100 50.08 Miles O"Neal <meo@schoneal.com> 486DX4/100 50.08 Will <zxmvg07@hp12.zdv.uni-tuebingen.de> 486DX4/100 50.08 Piet de Bondt <bondt@dutiws.twi.tudelft.nl> 486DX4/100 laptop 50.08 Karl Kleinpaste <karl_kleinpaste@cs.cmu.edu> 486DX4/100 256c 50.08 Thomas Kanschik <y0000997@ws.rz.tu-bs.de> 486DX4/100 50.08 Linas Vepstas <linas@fc.net> 486DX4/100 50.08 Ed Daiga <daiga@engin.umich.edu> 486DX4/100 notebook 50.08 Gerry Quejada <fd863@cleveland.freenet.edu> 486DX4/100 AMD 50.08 B Schuller <schuller@ind136a.wi.leidenuniv.nl> 486DX4/100 50.08 J.L. Brothers <brothers@halcyon.com> 486DX4/100 50.08 David E.A. Wilson <david@cs.uow.edu.au> 486DX4/100 50.08 Mark Lumsden <root@titan2.physics.mcmaster.ca> 486DX4/100 50.08 Ashar <ashar@netcom12.netcom.com> 486DX4/100 50.08 Jacob Waltz <waltz@pcjiw.lampf.lanl.gov> 486DX4/100 50.08 Tom Sinclair <sinner@cafe.net> 486DX4/100 AMD 50.08 G. Skinner <gskinner@gwsunix1.crystalball.com> 486DX4/100 AMD 50.08 Nick Savoiu <nick@ritz.mordor.com> 486DX4/100 50.08 Thomas J Fisher <twb5odt@nmia.com> 486DX4/100 50.08 Pascal Pensa <pensa@aurora.unice.fr> 486DX4/100 50.08 Julian Bradbury <julian@xabcs.demon.co.uk> 486DX4/100 50.51 Frederic Potter <frederic@swing.ibp.fr> 486DX4/100 50.66 Bill Stegers <bill_ste@zeelandnet.nl> 486DX4/120 256c 59.1 Kevin <kalichwa@oakland.edu> 486DX4/120 AMD 59.80 Mark Tranchant <mat92@ecs.soton.ac.uk> 486DX4/120 AMD 59.80 Fred Broce <fbroce@atlanta.com> 486DX4/120 AMD 59.90 Marko Ovaska <ovaska@cc.helsinki.fi> 486DX4/120 AMD 59.80 Bob Purdon <bobp@mpx.com.au> 486DX4/120 AMD 59.80 Pat Young <dice@netbsd.warped.com> 486DX4/120 59.91 Will <zxmvg07@hp12.zdv.uni-tuebingen.de> 486DX4/120 AMD 256c 60.01 Angelo Haritsis <ah@doc.ic.ac.uk> 486DX4/120 forzado 60.45 Pascal Pensa <pensa@aurora.unice.fr> 486DX4/120 60.45 Neal Howard <neal@metronet.com> 486DX4/120 AMD 60.45 Oscar Belmar Madrid <obelmar@anakena.usach.cl> 486DX4/120 60.45 Jason Buchanan <jsb@digistar.com> 486DX4/120 60.45 Foersterling <dirk@informatik.uni-frankfurt.de> 486DX4/120 60.45 Bernd Hentig <bernd@finow.snafu.de> 5x86/133 AMD 66.15 Brad Wilson <bwilson@deltanet.com> 5x86/133 AMD 66.44 P Yli-Krekola <perttu@ntcmar01ba.ntc.nokia.com> 5x86/133 AMD 66.55 Andrew B. Cramer <cramer@ripco.com> 5x86/133 AMD 66.65 Geoff Raye <gtraye@igsrsparc2.er.usgs.gov> 5x86/133 AMD 66.7 Klaas Hemstra <hst@mh.nl> 5x86/133 AMD 66.80 N.N. <vp24njcb@ubvms.cc.buffalo.edu> 5x86/133 AMD 256c 67.10 Vasily Lewis <vlewis@iastate.edu> 5x86/133 AMD 67.10 James Reith <reith@racores.com> 5x86/133 AMD 256c 67.10 Yves Rougy <yrougy%siam@cal.fr> 5x86/133 AMD 256c 67.10 Peter A. Koren <pkoren@lvdc20.dseg.ti.com> 5x86/133 AMD 256c 67.10 Wim Joppe <joppe@xs4all.nl> 5x86/133 AMD 256c 67.10 Gunnar Stefansson <gunnars@rhi.hi.is> 5x86/133 AMD 256c 67.10 Vernard Martin <vernard.martin@cc.gatech.edu> 5x86/150 AMD forzado 74.75 Sergio Riveros <riveros@musca.unm.edu> 5x86/150 AMD forzado 74.75 Arthur K. Chan <artchan@cs.ucr.edu> 5x86/160 AMD forzado 79.87 M.Suencksen <msuencks@techfak.uni-bielefeld.de> 5x86/160 AMD forzado 79.89 Martin Vernon <martin@gw6hva.demon.co.uk> 5x86/160 AMD forzado 79.92 T. Zerucha <zerucha@shell.portal.com> 5x86/160 AMD forzado 80.36 Paul Colucci <pcolucci@acsu.buffalo.edu> 5x86/160 AMD forzado 80.36 Steinar Haug <sthaug@nethelp.no> 5x86/160 AMD forzado 80.36 James Daniel <triadmin@bga.com> 486DX5/160 Cyrix 80.36 David H.S. Oh <david@std.net>
9.6 Sistemas Pentium configurados extraña o defectuosamente
Sistema BogoMIPS Informador Pentium/66 2.18 Bob Myers <root@shyguy.lonestar.org> Pentium/90 notebook 9.5 Mark Maybee <markm@cs.colorado.edu> 6x86/120 Cyrix 52.32 Joel Boring <dwild@eskimo.com> Pentium/83 Overdrive 82.85 Brian Smith <smithb@laraby.tiac.net> Pentium/83 Overdrive 83.32 Scott Francis <mord@netcom.com> Pentium/83 Overdrive 82.94 Greg Spiegelberg <greg@owens.ridgecrest.ca.us> Pentium/83 Overdrive 83.35 Jacek Polewczak <jacek.polewczak@csun.edu> 6x86/120 P120+forza. 104.86 Howard Poe <falcor@kingsnet.com>
Sistema BogoMIPS Informador Pentium/60 23 Chien-An Chen <giant@nwu.edu> Pentium/60 23.96 Joost Helberg <jhelberg@nlsun8.oracle.nl> Pentium/60 23.96 Ulf Tietz <ulf@rio70.bln.sni.de> Pentium/60 Gateway 23.96 Manoj Kasichainula <mvkasich@eos.ncsu.edu> Pentium/60 23.96 Pierre Frenkiel <frenkiel@cdfap1.in2p3.fr> Pentium/60 23.96 Tim Oosterbroek <tim@astro.uva.nl> Pentium/60 NCR 3455 24 Mathias Koerber <mathias@solomon.technet.sg> Pentium/60 24 Joe Sloan <jjs@engr.ucr.edu> Pentium/60 24.0 Mark H. Wood <mwood@indyvax.iupui.edu> Pentium/60 24.13 Roland M. van Rijswijk <rijswijk@cs.utwente.nl> Pentium/66 25 Chuck Munro <chuckm@canada.hp.com> Pentium/66 26.63 Jason M. Naughton <jnaughto@ee.ryerson.ca> Pentium/66 26.84 Kelly Carmichael <kcarmich@cln.etc.bc.ca> Pentium/75 256c 29.5 Chris Dodd <cdodd@super.win.or.jp> Pentium/75 Intel 29.79 Scott M. Grim <sgrim@netwalk.com> Pentium/75 29.95 Steve Martin <smartin@mrg.uswest.com> Pentium/75 30.22 Zoran Marjanski <bagzor@enterprise.ca> Pentium/75 30.22 Andrew Buckby <c4ab1@dmu.ac.uk> Pentium/75 30.22 Stuart Nuttall <u9230106@sys.uea.ac.uk> Pentium/90 notebook 32.73 Rich Neves <neves@cs.colorado.edu> Pentium/90 34.07 Alistair Galbraith <ajgalb@postman.essex.ac.uk> Pentium/90 zappa 256c 35.6 Sebastien Dedieu <dedieu@emi.u-bordeaux.fr> Pentium/90 35.88 Joe Anderson <CPJJA@ttacs3.ttu.edu> Pentium/90 35.88 Warwick Allison <warwick@cs.uq.oz.au> Pentium/90 36 Joe Sloan <jjs@engr.ucr.edu> Pentium/90 36 Larry Auton <lda@nfa.research.att.com> Pentium/90 36 Richard Knipe <knipe@lobby.ti.com> Pentium/90 36.0 Werner Almesberger <almesber@lrc.epfl.ch> Pentium/90 36.06 Rob J. Nauta <rob@iaehv.nl> Pentium/90 36.08 Leung Hon Wa <cshwleun@cs.citu.edu.hk> Pentium/90 Zeos 36.08 Chris Laurel <claurel@mr.net> Pentium/90 36.08 Ronald Prague <ronp@fishnet.net> Pentium/90 36.08 Adrian Blues <adrian@hypereality.co.uk> Pentium/90 36.08 Pak Yin Tam "Fred" <ptam@eesun1.tamu.edu> Pentium/90 36.08 Jason Heiss <jheiss@cco.caltech.edu> Pentium/90 36.08 Tim Krantz <tek@dsinc.com> Pentium/90 Gateway 36.08 Pete Stewart <stewart@bae.bellcore.com> Pentium/90 36.08 Tom Manos <tmanos@infi.net> Pentium/90 36.08 Richard Mundell <R.Mundell@uea.ac.uk> Pentium/90 36.08 NN <usenet@uxmail.ust.hk> Pentium/90 36.08 Yavuz Batmaz <yavuzb@knidos.cc.metu.edu.tr> Pentium/90 36.08 Alan Skelley <askelley@gpu.srv.ualberta.ca> Pentium/90 36.08 Ralph Sims <ralphs@locus.halcyon.com> Pentium/90 36.08 Julian Bradbury <julian@xabcs.demon.co.uk> Pentium/90 36.08 Dan Langrill <langrlld@mussel.cig.mot.com> Pentium/90 36.08 Ravi Krishna Swamy <rkswamy@eos.ncsu.edu> Pentium/90 36.08 J.L. Brothers <brothers@halcyon.com> Pentium/90 Micronics 36.09 Andrew Brown <andrewbrown@acm.org> Pentium/90 36.27 Giao H. Phan <giao@concrete.resnet.upenn.edu> Pentium/90 Plato 36.4 Joe Valenzuela <smarm@ibm.net> Pentium/90 36.5 Mike Kelleher <mikejk@umfacad.maine.edu> Pentium/90 36.9 Ted Gaunt <tgaunt@pms701.pms.ford.com> Pentium/100 39.52 Adrian Blues <adrian@hypereality.co.uk> Pentium/100 forzado 39.73 Phil Howard <phil@clr.com> Pentium/100 39.73 Weiss <Peter.Weiss@informatik.uni-oldenburg.de> Pentium/100 0c 39.73 Jason Crawford <jasonc1@gramercy.ios.com> Pentium/100 39.93 Tom Miller <tvtom@en.com> Pentium/100 Cyrix 39.94 Mike Holland <myk@cygnus.uwa.edu.au> Pentium/100 39.94 KAZ Vorpal <kaz@upx.net> Pentium/100 forzado 39.94 Donar G.E. Alofs <donar@cs.vu.nl> Pentium/100 39.94 Larry Snyder <larry@trauma.iag.net> Pentium/100 39.94 Ian Hill <ian@hecate.phy.queensu.ca> Pentium/100 39.94 John Crawford <link@spu.edu> Pentium/100 39.94 Jered <jered@mit.edu> Pentium/100 forzado 39.94 Ian <irs2@tweedledum.amp.york.ac.uk> Pentium/100 39.94 Brian McGhee <brianm@iceonline.com> Pentium/100 39.94 M Skjelland <morten.skjelland@pvv.unit.no> Pentium/100 39.96 Dan Kha <dkha@yorku.ca> Pentium/100 39.98 Phillipe Charon <charron@ecoledoc.ibp.fr> Pentium/100 40.03 <bon@elektron.ikp.physik.th-darmstadt.de> Pentium/100 40.08 Ronny Spiegel <rspiegel@htwm.de> Pentium/100 40.18 David Baldwin <davidb@exis.net> Pentium/100 40.18 <habibie@catevr.fiu.edu> Pentium/120 Cyrix 47.8 Simon Ho <simon@epsilon.win-uk.net> Pentium/120 Cyrix 47.92 Joel N. Squire <squire@colorado.edu> Pentium/120 47.93 Umberto d"Ortona <umberto@grenet.fr> Pentium/120 Cyrix 47.93 Jim T. Polk <jtpolk@cris.com> Pentium/120 47.93 Jon Trowbridge <trow@mcs.com> Pentium/120 47.98 Craig Bates <cbates@psu.edu> Pentium/120 Cyrix 48 Steve <horne@mhd2.pfc.mit.edu> Pentium/120 48.00 Michael Wazenski <mwazenski@dsrnet.com> Pentium/120 Intel 48.02 Scott M. Grim <sgrim@netwalk.com> Pentium/120 Cyrix 48.27 Glenn T. Jayaputera <gjt@budgie.apana.org.au> Pentium/120 48.27 Roman Mitnitski <mitnits@shany.net> Pentium/120 48.27 Peter Walsh <pwalsh@rain.org> Pentium/120 Cyrix 48.2 S Viznyuk <sviznyuk@magnus.acs.ohio-state.edu> Pentium/120 49.27 Simon Hargrave <simon@revell.demon.co.uk> Pentium/133 53.04 Wayne Roberts <wroberts@aug.com> Pentium/133 53.04 Gregory Travis <greg@indiana.edu> Pentium/133 53.25 Chuck Mattern <cmattern@mindspring.com> Pentium/133 53.26 Glenn Holt <gholt@lsil.com> Pentium/133 53.26 Chaim Tarshish <chaim@ipl.med.nyu.edu> Pentium/133 53.26 Mitchell B. Hamm <hamm@one.net> Pentium/133 53.26 Donald Lewis <dlewis@jackson.freenet.org> Pentium/133 53.26 Jon Trowbridge <trow@kremlin.emccta.com> Pentium/133 53.26 Charny Peete Mitchell <cpmiche@eos.ncsu.edu> Pentium/133 256c 53.26 David Wuertele <dave@gctech.com> Pentium/133 256c 53.68 Guiseppe Miceli <ferdy@ccii.unipi.it> Pentium/133 53.68 Michael Kress <kress@hal.saar.de> Pentium/150 Intel 59.80 Joel D. Young <jdyoung@afit.af.mil> Pentium/150 forzado 60.21 Duarte Cordeiro <l38404@alfa.ist.utl.pt> Pentium/166 66.16 Pedro Soria-Rodriguez <sorrodp@wpi.edu> Pentium/166 66.35 Krishnakumar Visweswaran <kviswesw@lehman.com> Pentium/166 66.44 Donald Lewis <dlewis@jackson.freenet.org> Pentium/166 67.10 Jon Trowbridge <trow@mcs.com> Pentium/166 67.10 Dylan <dylan@ert.com> Pentium/166 512c 67.10 Dirk Freese <freese@infra.de>
9.8 Variaciones de sistemas Pentium normales
SMP Pentium/90 71.98 Daniel Luhde-Thompson <dl10010@cam.ac.uk> SMP Pentium/90 72.08 Alan Cox <alan@cymru.net> SMP Pentium Pro/200 398.6 Bill Davidsen <davidsen@tmr.com> SMP Pentium Pro/200 398.95 Fons Rademakers <f.rademakers@cern.ch> SMP Pentium Pro/200 398.98 Greg Fausak <glfausak@august.com> Pentium Pro/133 132.88 John D. Sundberg <jdsundberg@mmm.com> Pentium Pro/180 179.61 Chuck Fee <fee@ch4549.org> Pentium Pro/200 197.42 Michael Griffith <grif@cs.ucr.edu> Pentium Pro/200 197.42 Curtis Varner <carner@cs.ucr.edu> Pentium Pro/200 198.84 Erik Max Francis <max@alcyone.com> Pentium Pro/200 198.84 Marc Winkler <marcus@healthchex.com> Pentium Pro/200 199.04 V. Bostrom <Vareck_Bostrom@ccm.jf.intel.com> Pentium Pro/200 199.06 Glenn Lamb <mumford@netcom15.netcom.com> Pentium Pro/200 199.07 Stefan <boresch@schuber.u-strasbg.fr> Pentium Pro/200 199.07 Chris Jones <chris@planetsymphone.com> Pentium Pro/200 200.32 Jose Navarro <jnavarro@aoc.nrao.edu> Pentium Pro/200 200.32 Wayne Scott <wscott@ichips.intel.com> Pentium Pro/200 200.32 Adrian L. Hosey <ahosey@cs.indiana.edu> 5x86/100 Cyrix 100.16 NN <root@anxa04.cc.ic.ac.uk> 5x86/100 100.19 Valient Gough <vgough@teton.mines.edu> 5x86/100 Cyrix 100.47 C.Chan <chan@alfrothul.uchicago.edu> 5x86/120 Cyrix P150+ 119.60 Wynstan Tong <wynstan@eecg.toronto.ca> 5x86/120 Cyrix P150+ 119.60 Joel N. Squire <squire@colorado.edu> 5x86/120 Cyrix P150+ 119.83 Leland Olds <olds@eskimo.com> 5x86/120 Cyrix P150+ 119.83 NN <root@anxa04.cc.ic.ac.uk> 5x86/120 Cyrix P150+ 120.68 C.Chan <chan@alfrothul.uchicago.edu> 5x86/133 Cyrix P166+ 132.88 Craig Andersen <andersen@fastlane.net> 6x86/100 Cyrix 99.42 Stig M. Valstad <svalstad@sn.no> 6x86/120 Cyrix 120 John C. Beasley <beaslej1@nevada.edu> 6x86/120 Cyrix P150+ 119 Jean-Claude Gouiran <jcg13@ibm.net> 6x86/120 Cyrix P150+ 119.60 Taso Lyristis <taso@remus.rutgers.edu> 6x86/120 Cyrix P150+ 119.83 Roger Merchberger <zmerch@northernway.net> 6x86/133 Cyrix P166+ 132.82 Alex Liffers <aliffers@tartarus.uwa.edu.au> 5k86/90 AMD 179.40 <root@krabi.mbp.ee> 5k86/90 AMD 181.00 Drew Golden <golden@platinum.nb.net> 5k86/90 AMD 179.40 Ken Edwards <edwards@thor.xon.cuug.ab.ca>
Sistema BogoMIPS Informador 21064/150 Jensen 148.37 Linus Torvalds <torvalds@cc.helsinki.fi> 21064/150 Jensen 149.49 J.L. Brothers <brothers@halcyon.com> 21064/150 Jensen 148.89 Martin Osterman <ost@comnets.rwth-aachen.de>k 21064A/275 Cabriolet 272 Linus Torvalds <torvalds@cc.helsinki.fi> 21064A/275 272 Stephen Gaudet <sjg@tiac.net> 21064A/275 Cabriolet 272.63 Jay Estabrook <jestabro@amt.tay1.dec.com> 21064A/275 Cabriolet 273.37 David Mosberger-Tang <davidm@cs.arizona.edu> 21064A/275 274.11 Kevin Jacobs <jacobs@eek.cwru.edu> 21064A/300 Cabriolet 298 Jay Estabrook <jestabro@amt.tay1.dec.com> 21064A/300 298 Stephen Gaudet <sjg@tiac.net> 21066/166 164.59 David Mosberger-Tang <davidm@cs.arizona.edu> 21066/166 165 Gareth Bult <gareth@ftech.net> 21066/166 165.04 Craig Ruff <cruff@ncar.ucar.edu> 21066/200 196.9 Danny ter Haar <danny@cistron.nl> 21066A/233 AS400 230.16 Ophir Ronen <ophir@connectsoft.com> 21066A/233 NoName 230.67 T. Bogendoerfer <tsbogend@bigbug.franken.de> 21066A/233 NoName 230.76 Mikael Nykvist <viper@ludd.luth.se> 21066A/233 NoName 231.21 Jay Estabrook <jestabro@amt.tay1.dec.com> 21066A/233 NoName 231.21 Wim van Dorst <baron@clifton.hobby.nl> 21164/266 EB164 265.29 Jay Estabrook <jestabro@amt.tay1.dec.com> 21164/333 Alcor 331.35 Linus Torvalds <torvalds@cs.helsinki.fi> 21164/333 Alcor 331.35 David Mosberger-Tang <davidm@azstarnet.com>
9.10 Sistemas Motorola normales
Sistema BogoMIPS Informador 68030/16 Atari Falcon 3.95 J.L. Brothers <brothers@halcyon.com> 68030/16 Atari Falcon 3.98 <Roman.Hodek@informatik.uni-erlangen.de> 68030/20 0c 4.92 Chris Nadigh <chrnadig@iiic.ethz.ch> 68030/25 Amiga 3000 6.21 Hamish Macdonald <hamish@bnr.ca> 68030/25 Amiga 3000 6.21 J.L. Brothers <brothers@halcyon.com> 68030/32 Atari Falcon 7.91 Franz Korntner <fkorntne@bazis.nl> 68030 Atari TT 7.96 <schwab@issan.informatik.uni-dortmund.de> 68030/32 Atari MegaST 7.98 E.J. van den Bussche <busscheh@ksepl.nl> 68030/33 Atari TT 7.98 <Roman.Hodek@informatik.uni-erlangen.de> 86030 Atari TT 7.98 Wayne Booth <trek@ihgp114r.ih.att.com> 68030/48 32c 11.89 Martin Rogge <Martin_Rogge@ki.maus.de> 68030/50 Atari 12 <Roman.Hodek@informatik.uni-erlangen.de> 68030/50 32c 12.42 Michael Plonus <michi@pluto.ping.de> 68040/24 Amiga 4000-40 16.6 Hamish Macdonald <hamish@bnr.ca> 68040/24 Amiga 4000-20 16.60 J.L. Brothers <brothers@halcyon.com> 68040/25 Amiga 4000-040 16.61 <Geert.Uytterhoeven@cs.ku-leuven.ac.be> 68040/25 Amiga 4000 16.61 Lawrence <lawrenc@nextwork.rose-hulmand.edu> 68040/66 Medusa T60 22 <Roman.Hodek@informatik.uni-erlangen.de> 68060/50 Amiga 4000 100.16 Jan Johansson <jj@mordor.it.kth.se>
9.11 Otros sistemas: Sparc, PowerPC, Mips, Intel 8088
Sistema BogoMIPS Informador Intel 8088/4.77 0.02 Tim Van der Linden <timvdl@innet.be> Intel 8088/10 0.05 Tim Van der Linden <timvdl@innet.be> Intel 8086 0.5 Kin Lau <gabe@zot.io.org> Sparc Sun4c 17.94 J.L. Brothers <brothers@halcyon.com> PowerPC 601/60 Mac6100 45.24 J.L. Brothers <brothers@halcyon.com> PowerPC 601/66 Mac 51.62 Fred Klein <klein@des3.u-strasbg.fr> PowerPC 601/60 Mac6100 59.38 Kent Radek <goo@itd.sterling.com> Mips R4000/100 48.30 J.L. Brothers <brothers@halcyon.com> Mips R4000/100 Magnum 50.03 Andreas Busse <andy@soft-n-hard.de> Mips R4400/134 Acer Pica 67.10 Andreas Busse <andy@soft-n-hard.de> Mips R4400/134 Acer Pica 67.10 Ralf Baechle <ralf@waldorf-gmbh.de> Mips R4600/133 Tyne 133.12 Ralf Baechle <ralf@waldorf-gmbh.de>
9.12 Sistemas no basados en Linux (sólo referencia)
Sistema S.O. BogoMIPS Informador 68020/20 Sun 3 SUNOS 2.0 <korpela@ssl.berkeley.edu> 68020/25 Sun 3-180 SUNOS 4.0 <korpela@ssl.berkeley.edu> Sparc Sun 3-60 SUNOS 4.00 <tranter@software.mitel.com> Sparc Sun 3-80 SUNOS 4.00 <tranter@software.mitel.com> 68040/33 HP9000-280 HP-UX 14 <niles@axp745.gsfc.nasa.gov> Sparc Sun 4-280 SUNOS 16.0 <korpela@ssl.berkeley.edu> Sparc Sun IPC/40 Solaris 16.00 <gong@cs.msu.su> 68040 NextStep (?) 16.26 <petergun@coffeehaus.com> Sparc Sun Sparcstation1 SUNOS 18.00 <tranter@software.mitel.com> Sparc Sun Sparcstation1+ SUNOS 19 <swmike@uplift.df.lth.se> Sparc Sun Sparcstation1+ SUNOS 24.00 <tranter@software.mitel.com> Sparc Sun IPC SUNOS 24.00 <tranter@software.mitel.com> Sparc Sun Sparcstation2 SUNOS 26.00 <gong@cs.msu.su> SparcClassic/50 Solaris 32.00 <gong@cs.msu.su> Sparc Sun ELC SUNOS 32.00 <tranter@software.mitel.com> HP-PA 9000-720 HP-UX 32.00 <metod.kozelj@rzs-hm.si> Sparc Sun SS10 SUNOS 34.00 <tranter@software.mitel.com> Pentium/100 Win-NT 36.21 <marcus@healthchex.com> Sparc Sun Sparcstation2 SUNOS 38.0 <korpela@ssl.berkeley.edu> Mips R4000/100 Indy (?) 48.00 <p.verwer@organon.akzonobel.nl> Mips R4000/100 SGI IndySC Irix 48.00 <lziegler@csbsju.edu> HP-PA 9000-720 HP-UX 48.00 <metod.kozelj@rzs-hm.si> Sparc Sun Sparcstation10d SUNOS 54.0 <korpela@ssl.berkeley.edu> Sparc SS1000 2CPU SUNOS 58.00 <gong@cs.msu.su> Alpha 21064/133 Decstation OSF1 64 <niles@axp745.gsfc.nasa.gov> Sparc Sun SS5 SUNOS 68.00 <tranter@software.mitel.com> Sparc Sun SS20 SUNOS 72.00 <tranter@software.mitel.com> Sparc Sun SS20/712 Solaris 74 <spohr@qmos> Mips R4400/150 Challenge (?) 74.00 <p.verwer@organon.akzonobel.nl> Mips R4400/150 Indigo2Extr (?) 74.00 <p.verwer@organon.akzonobel.nl> HP-PA 9000-715 HP-UX 74.00 <metod.kozelj@rzs-hm.si> Alpha OSF1 92.00 <petergun@coffeehaus.com> Mips R4400/200 Indigo2Extr (?) 98.00 <p.verwer@organon.akzonobel.nl> HP-PA 9000-735/99 HP-UX 98.00 <lankhors@cs.rug.nl> Sparc Sun SS4/110 Solaris 108 <spohr@qmos> Sparc Sun SS5 SUNOS 110 <swmike@uplift.df.lth.se> Alpha 21064A/233 OSF1 114 <niles@axp745.gsfc.nasa.gov> HP-PA 700/125 HP-UX 122 <niles@axp745.gsfc.nasa.gov> HP-PA 9000-735/125 HP-UX 122.00 <lankhors@cs.rug.nl> Mips R4600/133 SGI Indy Irix 132 <lziegler@csbsju.edu> Alpha OSF1 180.0 <mauger@ensinfo.univ-nantes.fr> Sparc Sun US1/170 Solaris 330 <spohr@qmos> Alpha 3000/600S VMS 348.61 <metod.kozelj@rzs-hm.si> Alpha server 1000-4/200 VMS 397.68 <metod.kozelj@rzs-hm.si> Cray J90 Y-MP/100 16CPU Unicos 912.00 <lankhors@cs.rug.nl>
10. Nota sobre la traducción al español
La presente traducción de este documento ha sido realizada por Juan Carlos Durán García jcdg@hotmail.com, componente del proyecto INSFLUG.
El INSFLUG forma parte del grupo internacional Linux Documentation Project, encargándose de las traducciones al castellano de los Howtos (Comos), así como la producción de documentos originales en aquellos casos en los que no existe análogo en inglés. En el INSFLUG se orienta preferentemente a la traducción de documentos breves, como los COMOs y PUFs (Preguntas de Uso Frecuente, las FAQs. :) ), etc. Diríjase a la sede del INSFLUG para más información al respecto.
En la sede del INSFLUG encontrará siempre las últimas versiones de las traducciones: www.insflug.org. Asegúrese de comprobar cuál es la última versión disponible en el Insflug antes de bajar un documento de un servidor réplica. Se proporciona también una lista de los servidores réplica (mirror) del Insflug más cercanos a Vd., e información relativa a otros recursos en castellano. Francisco José Montilla, pacopepe@insflug.org.
BTTV Mini-Como
Por Eric Sandeen,eric_sandeen@bigfoot.com
Traducción de Félix Martos Trenado, asinkecualo@mail.com
Traducción: v0.1, Febrero 2000 Original: v0.3, February 2000
Este documento describe el hardware, el software, y los procedimientos necesarios para usar una capturadora de vídeo o una tarjeta de TV, basadas en los chipsets bt8x8, bajo Linux.
6. Apéndice A - Argumentos para todos los módulos
La posibilidad de capturar y ver fuentes de vídeo es una de las más interesantes características multimedia de Linux. Están soportados varios dispositivos de vídeo a través de la API video4linux (http://roadrunner.swansea.uk.linux.org/v4l.shtml), entre ellos varias tarjetas de TV basadas en los chipsets de Conexant bt848 y bt878. Este documento explica como usar estas tarjetas en un sistema Linux.
1.1 Copyright de este documento
El copyright sólo se traduce de forma informativa, por eso mantenemos el original, que es la única versión válida.
This HOWTO is copyrighted 1999 Eric Sandeen. Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO co-ordinator at the address given below.
In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs. If you have questions, please contact Tim Bynum, the Linux HOWTO co-ordinator, at linux-howto@metalab.unc.edu via email.
BTTV-Mini-HOWTO es propiedad intelectual (C)1999 de Eric Sandeen A menos que se establezca otra cosa, los titulares de los HOWTO de Linux son sus respectivos autores. Los HOWTO de Linux pueden reproducirse y distribuirse en todo o en parte, en cualquier medio físisco o electrónico, mientras se mantenga este aviso de copyright en todas las copias. La redistribución comercial está permitida y se anima a ello; de cualquier manera, al autor le gustaría que le fuese notificada su distribución. Todas las traducciones, los trabajos basados en o que agrupen cualquier documento de los HOWTO de Linux deben estar cubiertos por esta misma licencia. Es decir, no puedes producir un trabajo derivado de un HOWTO e imponer restricciones adicionales en su distribución. Pueden hacerse excepciones a estas reglas bajo ciertas condiciones; por favor contacte con el coordinador de Linux Howto en la dirección proporcionada infra.
Resumiendo, queremos promover la propagación de esta información a través de tantos medios como sea posible. Aunque deseamos retener el copyright de los HOWTO, y nos gustaría que se nos informara de cualquier plan para redistribuirlos. Si tiene Usted alguna pregunta, contacte con Tim Bynum, el coordinador de los HOWTO de linux en linux-howto@metalab.unc.edu a través de correo electrónico. Para la traducción de este howto, contacte con su autor o con el proyecto Insflug en http://www.insflug.org.
1.2 Dónde obtener este documento
La más reciente versión oficial de este documento puede obtenerse en el Proyecto de Documentación de Linux (LDP) http://metalab.unc.edu/LDP/. Las diversas versiones de la traducción se pueden obtener en INSFLUG http://www.insflug.org/, y en la página del traductor http://www.asinkecualo.org.
Gracias a Ralph Metzler y Marcus Metzler por escribir el driver original bttv. También a Alan Cox por crear la API de Video4Linux, Gerd Knorr por su trabajo en las tarjetas de radio, las sucesivas versiones de bttv y xawtv. Y a todo aquel que haya contribuido al soporte de estas tarjetas bajo Linux. Gracias a William Burrow, que también escribió un BTTV Howto (del que tuve noticias después de escribir este documento). Para escribir este HOWTO he buceado en la documentación de bttv y xawtv.
1.4 Renuncia de responsabilidad
Usa la información contenida en este documento por tu cuenta y riesgo. No me hago en absoluto responsable de la potencial peligrosidad del contenido de este documento. El uso de los conceptos, ejemplos u otro contenido de este documento queda completamente bajo tu responsabilidad.
Todos los copyrights son de sus propietarios, a menos que se haga notar específicamente lo contrario. El uso de cualquier término en este documento no debe afectar a la validez de cualquier marca comercial o registrada. El nombrar cualquier producto o marca no afecta a la validez de esa marca. Es muy recomendable que haga copias de seguridad de su sistema antes de cualquier instalación importante y de forma periódica.
Del README de bttv:
Bttv es un controlador de dispositivo para capturadoras de vídeo que usen la familia de chips Conexant (http://www.conexant.com) Bt848. entre estos se cuentan Bt848, Bt848A, Bt849, Bt878 y Bt879. La diferencia principal (y a veces la única) entre los diversos fabricantes es el tipo de sintonizador y algunos componentes adicionales en las tarjetas. Por ejemplo, algunas tarjetas de Hauppauge tiene un decodificador adicional de Teletexto (que no es necesario con el soft adecuado) o un decodificador de sonido. Sólo algunos de estos componentes adicionales están soportados por bttv. También pueden diferir el tipo de entradas (Compuesto o S-Video) y su número. Las siguientes tarjetas deben funcionar:
Para usar estas tarjetas de TV bajo Linux, necesitará los controladores de dispositivo apropiados en el núcleo. Los controladores de dispositivo de bttv son parte de la distribución del núcleo de Linux desde la versión 2.2.0.
Opcionalmente puede obtener la última versión del paquete de los controladores de dispositivo y usarlo con los kernel 2.0.35 y superiores. Aun así, no se garantiza que funcione con la anterior serie de núcleos 2.0.x. El paquete actualizado de bttv está disponible en http://www.strusel007.de/linux/bttv/.
Si es Usted nuevo en el mundo de los controladores de dispositivo de bttv, le sugerimos que comience con la versión incluida en el último núcleo. Si experimenta problemas con él, o encuentra que su tarjeta no está soportada, entonces atrévase con la serie 0.6 actualizada de los controladores de dispositivo en las direcciones arriba indicadas. Si te siente aventurero, puede probar la serie de drivers 0.7 de Gerd Knorr, que se incorporarán en los núcleos 2.4. Estos están disponibles en http://www.strusel007.de/linux/bttv/.
Este documento está basado principalmente en los controladores de dispositivo del núcleo 2.2.14, con alguna mención de las características de la serie 0.6. La serie 0.7 no está actualmente cubierta, ya que está en desarrollo mientras escribimos este documento.
Los nuevos controladores de dispositivo de la serie 0.7.x no funcionan con los núcleos 2.0.x
(Gracias a William Burrow por esta sección.) Si tiene miedo de abrir la carcasa de su ordenador, lea primero este documento completo y anota las características de su tarjeta, tales como sintonizador, número de sus circuitos integrados, la frecuencia de sintonización y datos similares.
En otro caso, abra su ordenador e instale la tarjeta en una ranura libre. Elija una que soporte la transferencia del bus PCI y el PCI Bus Mastering; si no sabe si su placa base tiene todas estas características, mírelo en su manual. Le harán falta para el modo Overlay.
Con respecto al sonido hay dos formas diferentes de conectar su tarjeta capturadora y la de sonido. Una es internamente. Conecte su cable de audio digital del lector CD-ROM a la entrada de sonido de la tarjeta de vídeo y la salida a la entrada de la de sonido, donde iba el cable del CD-ROM. Otra forma es conectar el conector «jack» externo de sonido de 3.5 mm. de la tarjeta de vídeo con la entrada de línea de la tarjeta de sonido. También puede, simplemente, conectar unos altavoces amplificados a la salida de la tarjeta de vídeo, si no tiene una de sonido o no le apetece pasarlo a través de ella. (Algunas tarjetas nuevas Bt878 no tienen ningún conector de sonido, ya que envían la señal digital de audio a través del bus PCI. No hay soporte para esto en el momento de escribirlo).
También es recomendable una fuente de vídeo para determinar si la tarjeta está funcionando o no. Algunas tarjetas manejan vídeo compuesto, S-Video y si tienen sintonizador entrada RF (N. del T.: La entrada de antena habitual). Hay un conector separado para cada entrada.
Su núcleo necesitará estar configurado para soportar su tarjeta. La mayoría de las nuevas distribuciones de Linux vienen con los módulos necesarios ya compilados, así podrá encontrar:
en /lib/modules/2.x.x/misc y ya tendría que estar todo dispuesto.
En otro caso, necesitará recompilar su núcleo con:
activados, preferiblemente como módulos para cargar. Mire en el Linux Kernel HOWTO (http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html) (o su traducción española, disponible en http://www.insflug.org) para más detalles acerca de la recompilación del núcleo.
4.3 Usar los paquetes 0.6.x actualizados
Si desea usar los paquetes 0.6.x actualizados, debe obtener primero el archivo de uno de los sitios mencionados arriba. Descomprímalo con la orden:
tar -xvzf bttv-0.6.x.tar.gz
y cámbiese al recién creado directorio con permisos de superusuario, y escriba make en el directorio principal para crear los controladores de dispositivo. (Puede ignorar tranquilamente la información del fichero INSTALL con respecto a editar los makefiles ya que pasaremos esta información al controlador de dispositivo, en forma de parámetros de los módulos.) Entonces teclee:
make install
para instalarlos y finalmente ejecute
/sbin/depmod -a
para actualizar las información sobre dependencias de los módulos.
4.4 Ficheros especiales en /dev
Después necesitará crear los fichero especiales de carácter en el directorio /dev. Teclee:
ls /dev/video*; ls /dev/radio*
para ver si ya existen. Si no existen necesitaremos crearlos. Todos los ficheros tendrán como major device number 81, y el minor device number dependerá del dispositivo específico (vídeo, radio, etc.) así como múltiples instancias de estos ficheros.
Mire en la API de Video4Linux (http://roadrunner.swansea.uk.linux.org/v4lapi.shtml) para los detalles relativos a la programación.
Hay un guión del intérprete de órdenes (script de shell) llamado MAKEDEV en el directorio driver del paquete de los controladores de dispositivo bttv, que creará por Usted cuatro dispositivos de vídeo. También puede hacerlo fácilmente Usted mismo, si sólo dispone de una tarjeta de vídeo. Como root, teclee:
mknod /dev/video0 c 81 0 chmod 666 /dev/video0 ln -s /dev/video0 /dev/video mknod /dev/radio0 c 81 64 chmod 666 /dev/radio0 ln -s /dev/radio0 /dev/radio
Hay también dispositivos de teletexto y VBI que pueden crearse si tiene alguna aplicación que los necesite (Actualmente son pocas). Teclee:
mknod /dev/vtx0 c 81 192 chmod 666 /dev/vtx0 ln -s /dev/vtx0 /dev/vtx mknod /dev/vbi0 c 81 224 chmod 666 /dev/vbi0 ln -s /dev/vbi0 /dev/vbi
El controlador de dispositivo bttv proporciona varios módulos diferentes, con distintas opciones, que se describen en el apéndice de este documento. Con tantos módulos y opciones, puede desear hacerlo todo a mano hasta tenerlo funcionando. En el caso de que esto pudiese ocasionar un bloqueo en el ordenador, no será perjudicial escribir:
sync; sleep 1; sync
para vaciar los buffers antes de proceder. Entonces, usando la orden insmod como el usuario root, intente cargar estos módulos. Los dos primeros son fáciles, ya que generalmente no necesitan ninguna opción:
insmod videodev insmod i2c
Ahora está preparado para cargar el propio módulo bttv:
modprobe -v bttv
Por defecto el módulo bttv intenta autodetectar su tipo de tarjeta. Observe /var/log/messages para ver lo que encuentra. Si no lo autodetecta correctamente, puede Usted añadir la opción card=n al final de la orden anterior para forzar un tipo de tarjeta, con n elegido de de la siguiente lista. (Se dan los tipos de 0 hasta 19, en los controladores de dispositivo del núcleo bttv-0.6.4h se incluye soporte para los tipos desde el 20 hasta el 27). Puede también añadir la opción radio=1 si su tarjeta tiene sintonizador de FM.
card=n card type
0: Autodetectar
1: Miro
2: Hauppauge (viejas tarjetas bt848)
3: STB
4: Intel
5: Diamond
6: AVerMedia
7: MATRIX Vision MV-Delta
8: FlyVideo
9: TurboTV
10: Hauppauge (nuevas trajetas bt878)
11: MIRO PCTV pro
12: Terratec/Vobis TV-Boostar
13: Nueva Hauppauge WinCam (bt878)
14: MAXI TV Video PCI2
15: Terratec TerraTV+
16: Aimslab VHX
17: PXC200
18: AVermedia98
19: FlyVideo98 (nuevas FlyVideo cards)
20: Zoltrix TV-Max
21: iProTV
22: ADS Technologies Channel Surfer TV
23: Pixelview PlayTV (bt878)
24: Leadtek WinView 601
25: AVEC Intercapture
26: LifeView FlyKit sin sintonizador
27: Intel Create and Share PCI
Después, cargue el módulo del sintonizador con: modprobe tuner type=n Probablemente necesite mirar en la tarjeta cuál es el que tiene. Algunas tarjetas (Miro y Hauppauge) permiten detectar automáticamente el sintonizador detectado, pero puede que necesite especificarlo. El sintonizador tendría que tener la marca y especificar si es NTSC o PAL. Para los PAL, está marcado con 28.xxxMHz (donde xxx son tres dígitos). Para NTSC, la chapa deberá rezar 35.xxxMHz. Una vez que lo tenga identificado, selecciona el valor de n de la lista siguiente (los tipos 8 y 9 están sólo incluidos en bttv-0.6.4h):
type=n tipo del chip sintonizador, n entre los siguientes:
0: sintonizador Temic PAL
1: sintonizador Philips PAL_I
2: sintonizador Philips NTSC
3: sintonizador Philips SECAM
4: sin sintonizador
5: sintonizador Philips PAL
6: sintonizador Temic NTSC
7: sintonizador Temic PAL
8: sintonizador Alps TSBH1 NTSC
9: sintonizador Alps TSBE1 PAL
(N. del T. En España ese utiliza el sistema PAL, como en la mayoría del continente europeo, exceptuando Francia, que usa SECAM. En América y Japón lo habitual es NTSC. Además los sintonizadores más corrientes son el Philips y el Temic, por lo que lo habitual en su tarjeta, suponiendo que esté en España, será 0 ó 5.)
Finalmente, inserte los módulos de sonido que necesite. De nuevo necesitará mirar detenidamente la tarjeta para saber lo que tiene. Tenga en cuenta que los controladores de dispositivo para los chips TEA6300, TDA8425, TDA9855 y DPL3518 sólo están incluidos en los controladores de dispositivo de la serie 0.6.4h y no lo están en los actuales (2.2.14) controladores de dispositivo del núcleo: (pruebe alguno de estos)
modprobe msp3400
tea3600
tda8425
tda9855
dpl3518
(consulte el apéndice para más detalles y opciones) Ponga en marcha tu programa favorito de video4linux y compruebe si funciona. Si no puede cambiar de canal, asegúrese de haber insertado el módulo con el sintonizador correcto. Si no escucha nada, compruebe el módulo del sonido, y que el canal no esté silenciado, si mete el audio a través de la tarjeta de sonido.
4.6 Automatización del proceso
Después de conocer qué módulos y opciones necesitas, puede automatizar el proceso poniendo la información en /etc/conf.modules. Entonces, al ejecutar una aplicación que necesite el controlador de dispositivo, se cargará automáticamente.
Nosotros utilizamos los siguientes:
# TV alias char-major-81 bttv pre-install bttv modprobe -k tuner; modprobe -k msp3400 options bttv radio=1 card=3 options tuner type=2
Asegúrese de cambiarlo para reflejar los módulos y opciones correspondientes a su tarjeta. (Ejecute
/sbin/depmod -a
para asegurarse de que toda la información de dependencias de módulos está actualizada).
(N. del T.: En nuestro caso tuvimos que añadir pll=1 al driver bttv. El tipo de tarjeta es el 6 y el sintonizador el 5. Utilizamos una Avermedia Capture 98)
Ahora que su núcleo y los dispositivos están configurados y los módulos insertados, necesitará una aplicación para ver y capturar imágenes desde su tarjeta. Hay varios disponibles:
Hay también disponible un controlador de dispositivo para el control remoto de la tarjeta FlyVideo98 en http://wolf.ifj.edu.pl/~jochym/FlyVideo98/Asegúrese de leer la documentación para cualquier aplicación que vaya a utilizar. Algunas de ellas necesitan editar previamente los ficheros de configuración para que la aplicación funcione correctamente. Debido a los diferentes tipos de tarjetas que existen por doquier, debe dedicar algo de tiempo a leer la documentación de cada una, ya que lo normal será que la configuración por defecto no funcione con su tarjeta.
6. Apéndice A - Argumentos para todos los módulos
Lo que vaya precedido por un "*" sólo está disponible en la serie 0.6.4h
videodev.o
es el módulo básico para video4linux, todos los controladores
de dispositivo (incluido bttv) se registran aquí
i2c.o
el módulo genérico i2c. Hace la mayor parte del control
del bus, todos los módulos (excepto videodev.o) lo usan
argumentos con insmod:
scan=1 escanea el bus en busca de
controladores de dispositivo i2c
verbose=0 calla a i2c
i2c_debug=1 para depuración, manda todo el tráfico
bus i2c a los registros del sistema
bttv.o
el driver bt848 (el chip capturador)
argumentos con insmod:
remap=adr remapea la memoria de Bt848 a direcciones<<20
vidmem=base dirección del frame buffer>>20 (tarjeta gráfica)
triton1=0/1 para compatibilidad con Triton1
Triton1 es reconocida automáticamente
pero puede ayudar con otros chipsets
pll=0/1/2 ajustes del pll
0: no usa PLL
1: 28 MHz crystal instalado
2: 35 MHz crystal instalado
radio=0/1 la tarjeta soporta radio
card=n tipo de tarjeta
0: Autodetectar
1: Miro
2: Hauppauge (antiguas tarjetas bt848)
3: STB
4: Intel
5: Diamond
6: AVerMedia
7: MATRIX Vision MV-Delta
8: FlyVideo
9: TurboTV
10: Hauppauge (nuevas trajetas bt878)
11: MIRO PCTV pro
12: Terratec/Vobis TV-Boostar
13: Nueva Hauppauge WinCam (bt878)
14: MAXI TV Video PCI2
15: Terratec TerraTV+
16: Aimslab VHX
17: PXC200
18: AVermedia98
19: FlyVideo98 (nuevas FlyVideo cards)
*20: Zoltrix TV-Max
*21: iProTV
*22: ADS Technologies Channel Surfer TV
*23: Pixelview PlayTV (bt878)
*24: Leadtek WinView 601
*25: AVEC Intercapture
*26: LifeView FlyKit sin sintonizador
*27: Intel Create and Share PCI
remapeo, tarjeta, radio y plll aceptan hasta cuatro argumentos separados
por comas (para múltiples tarjetas). La "CARD" y "PLL" definidas en el
Makefile se usan por defecto.
msp3400.o
El driver para los procesadores de sonido msp34xx. Si tiene una tarjeta
estéreo probablemente necesitarás cargar este módulo.
argumentos con insmod:
debug=1/2 pasa alguna información de depuración a los syslog,
2 es más verboso.
*tea6300.o
El driver para el chip de fader tea6300. Si tiene una trjeta estéreo
y el msp3400.o no funciona, debe probar este. Este chip se ve mucho en
tarjetas STB TV/FM (en ventas de remanentes de OEM's de Gateway en
sitios de subastas).
argumentos con insmod:
debug=1 pasa alguna información de depuración a los syslog.
*tda8425.o
El driver para el chip de fader tda8425. Este controlador de
dispositivo antes era parte de bttv.c, así que si funcionaba
antes y ahora no, pruebe a cargarlo
argumentos con insmod:
debug=1 pasa alguna información de depuración a los syslog.
*tda9855.o
El controlador de dispositivo para el chip descodificador
estéreo y de procesamiento de audio tda9855.
argumentos con insmod:
debug=1 pasa alguna información de depuración a los syslog.
*dpl3518.o
Driver para el procesador Dolby Pro Logic dpl3518a
argumentos con insmod:
debug=1 pasa alguna información de depuración a los syslog.
tuner.o
El controlador de dispositivo sintonizador. Lo necesita a
menos que sólo quiera usar la tarjeta con una cámara o un
sintonizador externo.
argumentos con insmod:
debug=1 pasa alguna información de depuración a los syslog
type=n tipo del chip sintonizador, n entre los siguientes:
0: sintonizador Temic PAL
1: sintonizador Philips PAL_I
2: sintonizador Philips NTSC
3: sintonizador Philips SECAM
4: sin sintonizador
5: sintonizador Philips PAL
6: sintonizador Temic NTSC
7: sintonizador Temic PAL
*8: sintonizador Alps TSBH1 NTSC
*9: sintonizador Alps TSBE1 PAL
i2c_chardev.o
proporciona un driver de carácter para el acceso al bus i2c. Funciona
sólo con los núcleos 2.1.x, no se compila por defecto.
Ejemplo breve de Linuxdoc-SGML
Matt Welsh, mdw@cs.cornell.edu
Traducido por Fco. José Montilla, pacopepe@insflug.org
v1.0, 28 Marzo 1994
Este documento es un breve ejemplo del uso del DTD Linuxdoc-SGML
Este documento es un breve ejemplo del uso del Linuxdoc-SGML DTD. Puedes formatearlo empleando el comando:
% sgml2txt example.sgml
esto producirá texto ASCII simple. Se puede producir también LaTeX, HTML y texinfo.
El observar el fuente de este fichero será instructivo para mostrar cómo usar varias de las estructuras del paquete Linuxdoc-SGML. Debe leerse también Linuxdoc-SGML, Guía de usuario, del archivo guía.sgml. Los fuentes son y parecen similares al LaTeX, como puede verse. Los párrafos se separan mediante líneas en blanco, y las macros se colocan entre signos "mayor-menor que". Es bastante simple.
He aquí algunos ejemplos de elementos que serán empleados en el fuente. Primero, descendamos a una subsección:
Como reza en la cabecera. Nótese que se precisa usar el comando p para comenzar el cuerpo de la sección, tras el comando sect1. He aquí
una subsubsección:
Esto es una subsubsección
Ok. Hay 5 niveles de secciones disponibles. Emplear los siguientes comandos:
Para obtenerlas. Este documento emplea el estilo article que es apropiado para HOWTOs y otros documentos; el estilo report, (que incluye el comando de sección chapt) deben ser los empleados en la documentacion del LDP.
Todo va bien, así que sigues tecleando, y quieres mostrar código de ejemplo, o un ejemplo de I/O con un programa, o cualquier cosa. Usa los "entornos" code o verb para ello, en el interior de un entorno screen, como este:
Este es un ejemplo de entorno "verb"
O también este:
Este es un ejemplo de entorno "code"
El entorno tscreen simplemente define un tamano de fuente pequeño, indentandolo de forma agradable. No es necesario para definir un entorno verb or code, pero sugiero que se haga así. La Linuxdoc-SGML, Guía de usuario , explica que caracteres especiales pueden y no pueden ser empleados bajo un entorno verb y code.
Y ¿qué hay sobre las referencias cruzadas? Esta sección ha sido marcada con el comando label; el uso de ref nos proporciona una referencia cruzada, como la que hay en en "Ver sección
test-ref"para mas señas. Hasta ahora, las referencias cruzadas no funcionaban en la transformación de nroff para texto ASCII simple.
Quieres fuentes, y las tenemos. Por supuesto no aparecen como son en la versión ASCII del texto, pero todas ellas sí son modeladas en los variados formatos de salida: boldface, emphasis, sans serif, slanted, typewriter, e ita lics.
Los listados son tambien fáciles. Simplemente, emplee el elemento
itemize con el comando item, como se observa aqui:
pueden ser empleadas, como aquí puede verse.
Esto es simplemente todo lo que se necesita para ponerse en marcha escribiendo documentos SGML, empleando linuxdoc-sgml DTD. Por favor, hazmelo saber si piensas que se debería cambiar o añadir algo a este documento.
Para que las tildes, eñes y demás elementos tipográficos característicos de nuestro idioma aparezcan al procesarlos, es preciso pasar el parámetro ' -l ' al sgml2xxx que se emplee, basta con ponerlos tal cual en el fuente; el sgml2xxx se encargará de expa ndirlos a ``&xxcute" etc...
El INSFLUG forma parte del grupo internacional Linux Documentation Project, encargándose de las traducciones al castellano de los Howtos (Comos), así como la producción de documentos originales en aquellos casos en los que no existe análogo en inglés. En el INSFLUG se orienta preferentemente a la traducción de documentos breves, como los COMOs y PUFs (Preguntas de Uso Frecuente, las FAQs. :) ), etc.
Diríjase a la sede del INSFLUG para más información al respecto. En la sede del INSFLUG encontrará siempre las últimas versiones de las traducciones:
www.insflug.org. Asegúrese de comprobar cuál es la última versión disponible en el Insflug antes de bajar un documento de un servidor réplica.
Se proporciona también una lista de los servidores réplica (mirror) del Insflug más cercanos a Vd., e información relativa a otros recursos en castellano. Francisco José Montilla, pacopepe@insflug.org.
EL CÓMO DEL UMSDOS
Jacques Gelinas, jacques@solucorp.qc.ca
Traducido por: Carlos García Arques cgarcia@dit.upm.es
v1.1, 13 November 1995
Umsdos es un sistema de ficheros de Linux sobre uno FAT. Ofrece una alternativa al sistema de ficheros ext2. Su objetivo principal es conseguir una más fácil coexistencia con los datos de una partición FAT, compartiéndola. En este documento primero se explica cómo usar umsdos con diversas configuraciones, y después se explica cómo funciona y se da alguna información. Se deja para el lector la decisión de si es una buena elección para él.
El proyecto umsdos comenzó en 1992 y se puso a disposición de la red en enero del 1994 en forma de parche. Se incluyó en la distribución estándar del núcleo (kernel) de linux en Julio, comenzando con el núcleo 1.1.36. umsdos fue pronto adoptado por la distribución Slackware, incluso antes de que fuera oficialmente incluido en el núcleo.
umsdos empezó a ser mejorado a partir del núcleo 1.1.60. Su rendimiento ha mejorado radicalmente, especialmente en lo que se refiere a escritura. A partir del 1.1.70 (más o menos), vuelve a ser estable. Un error de consideración fue corregido en Linux 1.2.2. El error en cuestión estaba dando la lata a los usuarios desde el principio (se cambiaba el nombre a algunos ficheros dando la impresión de que habían desaparecido). Nótese que la Slackware 2.2 aún incluye la versión 1.2.1 del núcleo, luego contiene ese error.
Está disponible como parche para los núcleos 1.0.x. Va incluido en los núcleos 1.2. Se puede compilar dentro del núcleo o cargarlo como módulo. Sin embargo, hay que tener en cuenta que hoy por hoy, si se quiere usar umsdos en forma de módulo cargable se debe también usar el sistema de ficheros Ms-DOS como módulo cargable. Esto es debido a una limitación en el sistema de módulos (algunos símbolos se exportan sólo cuando los controladores se instalan como módulos).
1.3 Distribuciones que lo soportan
Por el momento creo que sólo Slackware lo incluye. Seguramente me equivoco, así que por favor corregidme.
1.4 Lugar original donde encontrarlo
El lugar original de umsdos es sunsite.unc.edu. Se debe buscar en el directorio
/pub/Linux/system/Filesystems/umsdos.
Hay un montón de documentación sobre el funcionamiento interno de umsdos. Se encuentra disponible tanto en formato HTML como en formato texto en la misma ubicación que las utilidades.
Por lo que yo sé, la versión HTML no está disponible en ningún servidor de Web. Se debe transferir, destarrar, y leer localmente.
Jacques Gelinas
jacques@solucorp.qc.ca
2.1 El concepto de la pseudorraíz.
Mediante el uso de umsdos, Linux se puede instalar en una partición de DOS normal y corriente. Linux se instala entonces como segundo (o tercer) sistema operativo en la partición. Para evitar conflictos con los nombres de los ficheros (Si ya hubiera, por ejemplo, un directorio bin, o tmp, en el disco C:), umsdos utiliza un inteligente truco: La pseudorraíz. Todos los ficheros de Linux se instalan en un subdirectorio del DOS llamado linux. Generalmente C:\LINUX. La estructura normal de directorios de Linux/Unix va ahí. Así se tiene
C:\LINUX\BIN
C:\LINUX\ETC
C:\LINUX\LIB
C:\LINUX\ROOT
C:\LINUX\SBIN
C:\LINUX\TMP
C:\LINUX\USR
C:\LINUX\VAR
Cuando arranca, el umsdos trata de encontrar el directorio linux y el /linux/etc. Si existen, activa el modo pseudorraíz. Básicamente, el modo pseudorraíz cambia el directorio raíz de la partición a C:\LINUX con lo que queda el árbol de directorios convencional de Unix
/bin
/etc
/lib
/root
/sbin
/tmp
/usr
/var
A esta lista añade uno nuevo llamado DOS, que es un directorio virtual.
2.2 Lo que hay que saber de la pseudorraíz
Por ejemplo, si se arranca linux con un disquete de mantenimiento y se monta la que es habitualmente la partición raíz en /mnt, todos los directorios de linux se encontrarán en /mnt/linux/bin, /mnt/linux/etc, etc...
3. Distintos aspectos del funcionamiento de umsdos
Se pueden usar las mismas opciones que para el sistema de ficheros Ms-DOS. La opción conv= es cuestionable en un sistema umsdos. Yo sugiero evitarla. Las opciones que más probablemente se querrá usar son
Únicamente se debe recordar que umsdos trata los directorios no promovidos de la misma forma que el sistema de ficheros Ms-DOS. Las opciones de arriba se aplicarán globalmente a todos los directorios no promovidos. uid establece el propietario por omisión, gid establece el grupo por omisión, y umask establece los permisos por omisión.
3.2 Cómo establecer los valores por omisión para la raíz
umssetup sirve para establecer en tiempo de ejecución el propietario de la partición raíz. Para