FaqDrake

En FaqDrake, encontrarás respuesta a las preguntas más frecuentes relacionadas con Mandriva Linux.

Aviso de primer version: Linux-Mandrake'' 5.1 (Venice) : new linux-distribution.

Aviso de la primer distribucion Mandrake ahora conocida como Mandriva: Fuente: http://listserv.externet.hu/lists/linux/9807/msg00054.html 
---------- Forwarded message ----------
Date: Fri, 24 Jul 1998 11:35:35 +0200
From: Gaël Duval 
Reply-To: kde@lists.netcentral.net
To: KDE general mailing list 
Subject: Announce : `Linux-Mandrake'' 5.1 (Venice) : new linux-distribution.





                      L I N U X - M A N D R A K E


                          5.1 (Venice) RELEASE
                              July, 23 1998


                 http://www.linux-center.org/mandrake/


     ``A ready-to-work and easy-to-use Linux-Distribution''

                  Base : Linux RH 5.1 GPL and KDE 1.0




 I am very happy to announce that ``Linux-Mandrake'', version 5.1
 (Venice) is now out and downloadable for free. Please have a look
 at the official web-site on :

  http://www.linux-center.org/mandrake/

 for download instructions.


 o  What is Linux-Mandrake exactly ?
    ------------------------------

    Linux-Mandrake is an updated Linux-RH 5.1 GPL, with KDE 1.0 fully
    integrated and preconfigured in it. Those two parts have been
    (not so much) modified and improved to work properly together.


 o  The main goals of this new distribution are:
    -------------------------------------------

    - to provide a working and easy-to-install linux-distribution to
      people who don't want to spend too much time in installing and
      configuring their Linux system : just install it and USE IT.

    - to provide a very attractive, easy-to-use, Linux System for
      newbies coming from the very common OS that you know ;-)

    - providing a new distribution in a well-known linux environment
      (RH 5.1)

    For example, after having your new Linux-Mandrake installed, just
    type `startx' and your beautiful KDE window-manager comes without
    crying :-) Now, just click on the cd-rom icon (on your desktop)
    to mount and use it (it's the same for floppy disks). This is
    very simple and you do not need to be a privileged user for that !



 o  Contents:
    --------

    In Linux-Mandrake, you'll find all the RH 5.1 good softs provided
    with the RH 5.1 : Emacs 20.2 the famous text editor, Apache 1.2.6
    the famous web-server, Netscape 4.05 the famous web browser etc.

    We also have been kind enough to put _Gimp 1.0_, the Photoshop-
    clone in Linux-Mandrake 5.1 :-)

    I sincerely believe that Linux-Mandrake is one of the most
    powerful Linux-distribution, and certainly the easyest to use.


 o  Last things:
    -----------

    This is a first version for TESTS, although I *really* think
    it's at least as usable as a common linux-distribution :-)

    I'm still looking for FTP mirrors !!! Please contact me.

    More informations on http://www.linux-center.org/mandrake/

    A lot of feedback about Linux-Mandrake will be *very*
    appreciated :-)



                        Gael Duval - duval@criuc.unicaen.fr




 o  Many thanx to:
    -------------

    Stefane Fermigier (linux-center), Nat Makarevitch (linux-france),
    Arnaud Crespin, Philippe Blanfuney (NOL), Sebastien Blondeel,
    and my little brother Antoine, for helping me and believing in
    the project.

    The erm6.u-strabg.fr, ftp.sunet.se and ftp.asci.fr people for
    hosting this new linux distribution with enthusiasm (I'm looking
    for other ftp sites !)

    RedHat Software for their nice distributions.
    KDE developpers for their great work.

    My 6x86 overclocked CPU for having been kind enough not to burn
    when compiling all the Mandrake packages.

    And of course, Linus and the GNU people for having made all this
    amazing open-source hype possible.


 o  Linux-Mandrake more detailled contents:
    --------------------------------------

    Linux Kernel version: 2.0.34
    ld.so version: 1.9
    glibc version: 2.0.7
    egcs version: 1.0.2
    gcc version: 2.7.2

    RH Linux version: 5.1
    KDE version: 1.0
    XFree86: 3.3.2
    Gimp version: 1.0
    Apache version: 1.2.6
    Netscape Communicator version: 4.05
    emacs version: 20.2


    And of course, all the RH 5.1 RPM packages
    (UPDATED July, 17 1998) !

-------------------------------------------------------------

 http://www.linux-center.org/mandrake/

-------------------------------------------------------------



--
 ////////////////////////////////////////////////////////
// Gael DUVAL - Reseaux & Applications documentaires   //
/ LINUX, LINUX, LINUX                                ///
 /////////////////////////////////////////////////////



-- 
Send posts to:  kde@lists.netcentral.net
 Send all commands to:  kde-request@lists.netcentral.net
  Put your command in the SUBJECT of the message:
   "subscribe", "unsubscribe", "set digest on", or "set digest off"
**********************************************************************
This list is from your pals at NetCentral


es parte de la historia de MDK / MDiva :-D

Bugzilla de PLF

Si tienes problemas con algun paquete de PLF, debes crear un bug en el Bugzilla de PLF: https://plf.zarb.org/bugzilla/

Bugzilla Mandriva

Bugzilla es una aplicación web que se utiliza para rastrear los errores en el desarrollo de una aplicación, en este caso las del sistema operativo Mandriva Linux.

En BlogDRAKE tenemos varios artículos referentes a Bugzilla. Un buen usuario de Mandriva Linux debe saber usar esta herramienta para comunicar errores en el sistema ya que con ello ayuda a que se conozcan y se reparen.

Más información sobre Bugzilla:

El Bugzilla de Mandriva Linux se encuentra en esta dirección:

Buscador de Bugs

Busca bugs en Bugzilla.mandriva.com desde BlogDRAKE:

Busqueda

Encuentra un Bug especifico

Cómo crear una cuenta en Bugzilla de Mandriva Linux

El Bugzilla de Mandriva Linux tiene por lenguaje el idioma inglés, y aunque muchos usuarios quieren usar Bugzilla, no pueden leer en inglés. Con esta guía podrán crear una cuenta y votar en las solicitudes que se colocan en el Foro Caza de Bugs de BlogDRAKE. El votar los bugs y comentar (en inglés) es la forma mas rápida y eficiente de hacer que los desarrolladores de Mandriva escuchen lo que queremos. BlogDRAKE ya ha logrado que se reparen muchos bugs gracias a la involucración de la comunidad a través del foro Caza de Bugs. Si quieres que Mandriva te escuche o que implemente algo que tú deseas, el primer paso es crear una cuenta en Bugzilla:
  1. El bugzilla de Mandriva tiene dos direcciones:
    1. http://qa.mandriva.com
    2. http://bugzilla.mandriva.com
    Desde ambas puedes llevar a cabo el proceso de creación de una nueva cuenta, para lo que necesitas tener una cuenta de correo. En la página de Bugzilla presiona el enlace que dice: "New Account" (que traducido es "Nueva cuenta"):
  2. En el cuadro que dice: "E-mail address" (que traducido es "Dirección de correo electrónico"), escribes tu dirección de correo electrónico, luego presionas el botón que dice "Send" (que traducido es "Enviar").
  3. Entonces recibirás un correo de Bugzilla donde habrá dos enlaces, uno para aceptar la creación de la cuenta y otro para rechazarla. Debes presionar el primer enlace:
  4. Al presionar el enlace, te enviará a la página de Bugzilla y te pedirá que introduzcas la información para tu cuenta en el cuadro que dice:
    • "Real Name" ("Nombre real"), escribes tu nombre o apodo,
    • en el cuadro "Type your password" escribes tu contraseña
    • y en el cuadro "Re-type your password" vuelves a escribir tu contraseña para comprobación
    • presiona el botón "Send" ("Enviar"):
  5. Te enviará un mensaje donde dice que tu cuenta ha sido aceptada. Presiona el enlace que dice "Login" ("Iniciar sesión") y escribe la información de tu cuenta así:
  6. Para saber si estás dentro, tu dirección de correo debe aparecer igual que en la imagen:
Ahora con tu cuenta eres capaz de votar en los bugs. Los desarrolladores dan prioridad a los bugs más votados (aunque también depende de su nivel de importancia): un bug con muchos votos quiere decir que afecta a muchos o que muchos usuarios quieren que se implemente lo que el bug pide. Cuando quieras votar un bug lo puedes hacer por medio de los enlaces que colocamos en el Foro Caza de Bugs o directamente en Bugzilla en el enlace en cada bug que dice "Vote for this bug" ("Votar por este bug"). Aparecerá una lista con todos los bugs que has votado. Si está tachado es porque el bug está cerrado o ha sido resuelto. En esa lista el nuevo bug por el cual vas a votar aparecerá de otro color, selecciona la casilla al lado del bug y presiona el botón que dice "Change my votes" (está al final de la página). Anda crea una cuenta en Bugzilla y empieza a colaborar con el desarrollo de Mandriva Linux.

Motor de busqueda Mandriva Bugzilla para Firefox 2

Al igual que nuestro motor de busqueda en BlogDRAKE Mandriva Bugzilla tambien nos ofrece un motor de busqueda para Firefox 2 puedes agregarlo presionando el siguiente enlace:
Instalar Motor de busqueda Mandriva Bugzilla
Si prefieres no instalar nada en tu navegador tambien puedes hacer busquedas desde BlogDRAKE:
Bugzilla: Busqueda
O puedes usar el cliente Bugzilla de Mandriva Linux:
Bugzilla / Drakbug




Vota en Bugzilla Mandriva

Ahora puedes votar en Bugzilla desde BlogDRAKE tan solo escribe el numero del bug que quieres votar y se generara un enlace para hacerlo.



Vota >> BUG




¿Encontraste un error en Mandriva? Utiliza Bugzilla / Drakbug para comunicarlo

Entiendo que muchos novatos se disgustan por "bugs" imaginarios pero hay algunos que en realidad existen pero con quejarse no se resuelve nada asi que para esas ocasiones el procedimiento correcto es crear una cuenta en el Bugzilla de Mandriva Linux http://bugzilla.mandriva.com/crea_una_cuenta luego de crear la cuenta vas aqui y te logueas http://bugzilla.mandriva.com/login para subir un reporte de bug y que el problema sea solucionado :) tambien puede hacerse atraves del programa drakbug que sera mas sencillo y en español para aquellos que no quieran usar la interfaz en ingles de la pagina :) Recordemos que como comunidad debemos regresar algo a Mandriva no solo demandar un buen producto si no tambien colaborar en su desarrollo si bien no como un Developer bien podria ser atraves de enviar reportes de bugs aunque temo que muchos novatos mal entiendan este proceso y envien muchos bugs que solo existen en su cabeza pero creo que vale la pena intentar que se haga un buen uso de esta herramienta ademas creo que mas de algun desarrollador les enviara un bonito RTFM si lo que envian es algun producto de su imaginacion ;)

Cómo instalar drivers de la tarjeta gráfica

ATENCIÓN: agradecería correcciones sobre los, posiblemente muchos, fallos que haya en este documento antes de pasarlo a la documentación (y si es después también vale). Fallos tanto de contenido/conceptos como de estilo, porque estos días estoy espesito y me temo que me salió un manual más denso de lo deseable :) Una de las dudas más comunes es "¿Cómo instalo los drivers de mi tarjeta gráfica?". Aunque ya fue respondida infinidad de veces, esa duda sigue apareciendo en los foros de cuando en cuando. Así que ya es hora de hacer un manual sobre ello, para que la duda no vuelva a aparecer (o, si aparece, poder responder con un mero enlace). ¡Vamos a ello! Lo primero de todo es aclarar, por si fuese necesario, qué es un driver (en español, controlador, aunque por costumbre utilizo el término inglés). Un driver es un software (la parte lógica de un ordenador, la que sólo puedes maldecir) que permite al sistema "hablar" con una determinada pieza de hardware (la parte física del ordenador, a la que le puedes dar patadas). Es decir, los drivers permiten que tu Linux le diga a la tarjeta gráfica, a la tarjeta de sonido, al cdrom, etc, lo que tiene que hacer. Para un mismo hardware puede haber varios drivers distintos, que difieren en la estabilidad del driver, las funcionalidades a las que permite acceder, quién y por qué lo hizo, etc.

Drivers libres y privativos

En lo que respecta a la instalación de drivers para la tarjeta gráfica, el punto más importante a considerar es la licencia del driver: si es libre o privativo. Espera, ¿que no sabes qué son el software libre y el software privativo (ambos nombres están enlazados a sus artículos de Wikipedia en español donde podrás aprender más sobre el tema)? En resumidas cuentas, el software libre es aquél que puedes usar, copiar, modificar y distribuir libremente, y el privativo el que no (es decir, te priva de la libertad de hacer eso). Dejando a un lado motivos ideológicos y tecnológicos (el software libre es éticamente bueno y de más calidad técnica), el que un driver sea libre tiene una ventaja muy importante para los usuarios, y ésta es que el driver puede incluirse en el kernel de Linux (el software más básico del ordenador, que coordina todos los drivers). ¿Y qué ventaja tiene que un driver esté incluido en el kernel? Pues la ventaja es que si un driver está en el kernel, el hardware asociado funcionará sin tener que hacer nada especial (en la mayoría de los casos). ¿Quiere decir eso que si el driver no está en el kernel sudaré sangre para conseguir que funcione? En absoluto, es sencillo instalar un driver privativo. Pero entre que funcione sin más, o que haya que instalar algo para que funcione, yo prefiero lo primero ;) Actualmente, los 3 tipos de tarjetas gráficas más importantes y comunes son NVidia, ATI e Intel. Bueno, las tarjetas gráficas en sí pueden ser de muchas marcas distintas, pero los chips que utilizan suelen ser de una de esas tres marcas. No obstante, para los drivers lo que importa son los chips que utilizan, así que nos referiremos (incorrectamente) a las tarjetas gráficas y sus marcas para referirnos a los chips de las tarjetas gráficas y sus marcas. Y si no te quedó claro, vuelve a leerlo ;) Dependiendo del tipo de tarjeta, podemos tener disponibles drivers libres o privativos con diferentes características. En el caso de las Intel, los drivers oficiales (que ofrecen aceleración 2D y 3D) son libres. Aquí puede verse la lista de tarjetas soportadas. En el caso de NVidia, existen drivers oficiales tanto libres como privativos. La diferencia, notable, es que los libres sólo tienen aceleración 2D, mientras que los privativos tienen aceleración 3D. Aquí puedes ver la lista de tarjetas soportadas por los drivers privativos. Ha de tenerse en cuenta, además, que algunas tarjetas ya no se soportan en las versiones más modernas de los drivers, sino que deben usarse drivers "viejos" para hacerlas funcionar. Finalmente, para ATI existen drivers oficiales privativos, y drivers no oficiales libres, ambos con aceleración 3D. No obstante, reconozco no tener mucha idea sobre los drivers de ATI, por lo que quien quiera puede completar esta información ;) Además, existe un driver libre adicional, llamado vesa, que puede ser utilizado como último recurso si nuestra tarjeta no está soportada por ninguno de los demás drivers. No obstante, el driver vesa, aunque permite mostrar la interfaz gráfica, carece de aceleración. Es un driver muy básico a utilizar cuando no hay más opción. Con todo esto, la forma de instalar los drivers para nuestra tarjeta gráfica cambiarán dependiendo de si son libres o privativos. Es más, la forma cambiará incluso dependiendo del "sabor" de Mandriva que estemos utilizando, ya que algunos llevan de serie drivers privativos mientras que otros no.

Sabores de Mandriva

Los "sabores" de Mandriva son las diferentes ediciones disponibles de Mandriva: Free, One, Discovery y Powerpack. Mandriva Free es una edición gratuita que contiene única y exclusivamente software libre. Mandriva One es una versión en LiveCD, también gratuita, que incluye tanto software libre como drivers privativos. Discovery y Powerpack son versiones de pago de Mandriva que contienen software y drivers libres y privativos. Cabe notar que todo, absolutamente todo el software libre disponible en Mandriva puede obtenerse desde los repositorios públicos y gratuitos. Desde Mandriva 2007.1, también los drivers privativos están disponibles públicamente y de forma gratuita en el repositorio non-free (en versiones anteriores se encontraban en la rama de software no libre de PLF (Penguin Liberation Front)). Así pues, en cualquier sabor de Mandriva podemos instalar los drivers privativos desde los repositorios públicos. La instalación de los drivers libres es trivial en todos los sabores de Mandriva, al igual que ocurre con la instalación de los drivers privativos en Mandriva One, Discovery y Powerpack. La instalación de los drivers privativos en Mandriva Free tiene un poco más de miga, pero nada realmente complicado. Mandriva One es un LiveCD instalable, de forma que cuando arranca el sistema automáticamente selecciona el mejor driver disponible para la tarjeta gráfica y lo utiliza. Al instalar desde el icono del escritorio, ya instala el driver que está utilizando. Listo, nada más que hacer :D Mandriva Free, Discovery y Powerpack, en cambio, son DVDs de instalación/actualización. Esto quiere decir que es el usuario quien tiene el control sobre qué se instala, qué configuración se utiliza y demás. En la mayor parte de los casos, el propio instalador deduce qué driver de los que tiene disponibles (recordemos que la edición Free sólo tiene drivers libres) es el más apropiado para nuestra tarjeta. No obstante, en ciertas ocasiones tenemos que darle una ayudita. Así, al llegar a la ventana de configuración del instalador, donde se especifica la configuración de la tarjeta gráfica, de la impresora, de la tarjeta de sonido, etc... puede darse el caso de que la tarjeta gráfica aparezca como "No configurada". Si ése fuese el caso, habría que pulsar en el botón "Configurar..." y especificar el modelo de la tarjeta gráfica y del monitor. El mismo programa mediante el que se configura la tarjeta gráfica en la instalación se utiliza para realizar dicha configuración en el funcionamiento normal del sistema: drakx11.

DrakX11

El lector atento se habrá percatado de que, por ahora, no abordamos cómo instalar drivers privativos en nuestra Mandriva Free. El lector más atento todavía, podrá suponer a raíz del título de este apartado y lo mencionado en el párrafo anterior que será ahora cuando lo expliquemos. Entre los múltiples y útiles asistentes de los que dispone Mandriva (recordemos que TODOS son software libre), tenemos drakx11 (también llamado XFdrake). Su función es la configuración de la tarjeta gráfica, el monitor y su resolución. Una característica importante a destacar de drakx11 es que tiene dos tipos de interfaces de usuario: gráfica y en consola. Dependiendo de si hay un servidor gráfico activo o no, al invocarlo automáticamente él mismo mostrará una interfaz u otra. Esto es muy útil cuando, por algún motivo, el servidor gráfico no funciona y tenemos que reconfigurarlo de nuevo. Incluso en esa situación, drakx11 seguirá funcionando y nos permitirá establecer la configuración fácilmente. Para que drakx11 (y algunos otros asistentes) pueda hacer su magia, generalmente los repositorios (concretamente, el repositorio non-free de Mandriva, o en su defecto de PLF) deben estar configurados (de modo que pueda instalar los paquetes que sean necesarios de forma automática). Esto es indispensable en un sistema instalado, aunque cuando se ejecuta drax11 desde el instalador del DVD no es necesario (es posible, no obstante, pero no necesario, ya que una vez instalado el sistema pueden configurarse los repositorios y reconfigurarse la tarjeta gráfica si durante la instalación no estuviese disponible el driver óptimo, como ocurriría en una Mandriva Free con los drivers privativos). Instalar paquetes adicionales deberá hacerse cuando el driver de la tarjeta gráfica esté en un paquete separado del kernel, es decir, cuando el driver sea privativo (ya que los drivers libres de tarjetas gráficas recordemos que van incluidos en el kernel). Por tanto, algunas tarjetas no necesitarán que los repositorios estén configurados para que drakx11 pueda usarse con ellas... pero eso no quita para que configurar los repositorios sea igualmente una de las primeras cosas que debe hacerse al instalar una distribución de Linux. Con todo esto, ¿cómo utilizo drakx11 para configurar mi tarjeta gráfica? Lo primero de todo, como es lógico, es arrancar drakx11. Hay varias posibilidades, a saber: Ahora que ya tenemos drakx11 abierto ante nosotros, simplemente pulsaremos en el botón al lado de Tarjeta gráfica. Esto nos mostrará una nueva ventana con una serie de marcas de tarjetas gráficas (bastantes más que NVidia, ATI e Intel, si bien muchas de ellas son marcas antiguas ahora desaparecidas que se mantienen en la lista por compatibilidad). Dentro de cada marca, aparecen las familias de tarjetas gráficas, no modelos concretos (ya que si fuese por modelos en lugar de por familias, la lista sería eterna). Seleccionamos la familia a la que pertenece nuestra tarjeta gráfica, y aceptamos. En caso de que para nuestra tarjeta gráfica haya disponible un driver privativo (bien porque los repositorios están configurados, bien porque sea el DVD de instalación de Mandriva Discovery o Powerpack), drakx11 nos preguntará si deseamos utilizarlo. Si aceptamos, él mismo instalará el driver y todo aquello que necesitase para hacerlo funcionar de forma automática. Además de la organización por marcas de la tarjeta gráfica, existe una categoría para drivers de X.Org, genéricos. Entre ellos están el driver vesa mencionado anteriormente, o nv, el driver libre de NVidia. Sin embargo, los drivers genéricos de X.Org deben usarse como última opción, cuando los drivers normales por familias de tarjetas no sirven. Es más, si se selecciona una tarjeta NVidia y no se escoge (o no está disponible) usar el driver privativo, implícitamente y de forma automática drakx11 escogerá por sí mismo el driver nv. Una vez instalado el driver (haya paciencia, ya que puede llevarle cierto tiempo en el caso de los privativos ;) ), de vuelta en la pantalla principal de drakx11, es importante probar la configuración seleccionada para evitar sorpresas. Pulsando el botón Probar deberían aparecernos una serie de rayas verticales en un patrón similar a varios arcoiris, y un diálogo preguntándonos si la configuración es correcta. Si vemos dichas rayas verticales y el diálogo, lo más probable es que la configuración sea correcta, por lo que podemos decirle que sí. Si la configuración no es correcta, la familia de tarjeta gráfica puede estar mal seleccionada, la resolución escogida puede ser superior a la máxima representable por el monitor... Lo mejor es revisar la configuración, y si sabemos que todo está bien... entonces estamos ante un problema. Si estábamos ejecutando drakx11 en modo gráfico, al salir nos dirá que debemos salir de la sesión y volver a entrar. Esto no es reiniciar el ordenador, sino simplemente salir de la sesión del usuario para que se pueda reiniciar el servidor gráfico y utilizar el nuevo driver escogido. Una vez hecho esto, y si todo fue bien, ya está. Ya tenemos nuestro driver instalado y funcionando. No fue tan complicado, ¿verdad? :)

DKMS

Es posible que te estés preguntando algo así como "Todo esto es muy bonito, pero si los drivers no están en el kernel, ¿qué pasa cuando actualizo el kernel? ¿Qué ocurre con los drivers?". Buena pregunta. Aquí es donde entra en juego DKMS. DKMS son las siglas de Dynamic Kernel Module Support (soporte para módulos dinámicos del kernel). Su función es permitir con facilidad el uso de drivers no incluidos en el propio kernel. Se utiliza tanto para drivers privativos, como para drivers libres muy específicos (por ejemplo, el driver kqemu utilizado por la máquina virtual qemu) que no están incluidos en el kernel. La idea es la siguiente. Ya que el driver no está en el propio kernel, DKMS compila los drivers cuando se arranca Linux con un kernel nuevo (sólo la primera vez que se arranca con dicho kernel). Una vez compilados, los drivers ya pueden usarse con el kernel en cuestión. Por tanto, si se utiliza DKMS, al actualizar el kernel y arrancar con él, los drivers propietarios de nuestra tarjeta gráfica se compilarán automáticamente sin que nosotros tengamos que hacer nada. Hay que tener una cosa en cuenta, eso sí. Para que los drivers puedan compilarse, debemos tener exactamente la misma versión del paquete kernel como del kernel-sources (que contiene el código fuente del kernel). En lugar del kernel-source, puede tenerse instalado el kernel-source-stripped, que es una versión reducida (sin comentarios en el código y cosas así) de los fuentes del kernel. Por defecto, el kernel y el kernel-source no se actualizan automáticamente, sino que ha de hacerse explícitamente. Así mismo, la actualización del kernel no implica la actualización del kernel-source, sino que debe indicarse también explícitamente. Éste es uno de los motivos por los que DKMS puede tener problemas: cuando se actualiza el kernel y por error no se actualiza su código fuente. No obstante, poniendo cuidado en este aspecto, no debería haber problemas. Cuando drakx11 instala los paquetes con los drivers propietarios para la tarjeta gráfica, instala 3 paquetes, a saber: driver, dkms-driver y driver-kernel (donde "driver" es el nombre del driver, por ejemplo, ati, nvidia96xx, etc). El primero contiene el driver binario para X.Org empaquetado para Mandriva. El segundo, el paquete DKMS del driver, que compila la interfaz del driver para el kernel (es decir, prepara el puente para poder usar el driver binario en el kernel). El tercero reconozco no estar muy seguro de qué es. Parece ser un paquete DKMS para una versión concreta del kernel (la indicada por la versión del paquete), pero desconozco su utilidad, ya que únicamente con los paquetes driver y dkms-driver debería funcionar. No existen dependencias entre ninguno de los tres paquetes, por lo que pueden instalarse o desinstalarse individualmente... con los problemas que ello puede conllevar (por ejemplo, que esté instalado el paquete DKMS, pero falte el binario, o viceversa). drakx11, no obstante, reinstala los paquetes que hubiesen podido ser eliminados por error, así que no hay problema ;)

¡Pero yo no tengo internet!

Hasta ahora, hemos asumido que los repositorios pueden ser usados sin ningún problema. No obstante, hay quien no dispone de Internet, por lo que no puede configurar los repositorios de paquetes por FTP/HTTP. Dado que drakx11 se apoya en la disponibilidad de los paquetes de los repositorios para instalar drivers privativos (de nuevo recordemos que para drivers libres no hay ningún problema), ¿qué podemos hacer? Posiblemente este tema daría para un manual por sí mismo, pero veremos aquí de forma resumida qué es lo que habría que hacer. De entre las opciones disponibles, veremos la más sencilla, aunque por ello también la menos práctica. Bueno, en honor a la verdad, la opción más sencilla sería comprar una Mandriva Discovery o Powerpack en caja e instalarla, o en su defecto descargar de algún modo una Mandriva One gratuita (aunque recordemos que ésta, aunque bastante completa, es un LiveCD mientras que las otras son DVDs, y por tanto incluyen más software). Pero asumiremos que, por la razón que sea, instalamos una Mandriva Free, queremos drivers privativos y no tenemos Internet en nuestro ordenador. Lo primero de todo es saber qué paquete tenemos que instalar. Es decir, hemos de averiguar el driver que utiliza nuestra tarjeta gráfica. Para ello, nada mejor que ir a la página web del fabricante y buscar ahí qué drivers son usados con qué tarjetas. Una vez sabemos qué driver necesitamos, descargamos los paquetes rpm driver y dkms-driver de algún repositorio y lo llevamos a nuestro ordenador. Ahora, abrimos una terminal y nos dirigimos en la terminal hasta el directorio que contiene el archivo rpm (para cambiar de directorio en consola se utiliza la orden cd directorioDestino). Una vez en dicho directorio, utilizaremos urpmq para conocer las dependencias del paquete que todavía no fueron instaladas: urpmq -m nombreArchivoDriver.rpm. Una vez conocemos las dependencias, las apuntamos en algún lugar, las descargamos manualmente desde un repositorio y las llevamos a nuestro ordenador sin Internet. Ubicamos dichas dependencias en el mismo directorio que el archivo rpm que contiene el driver, hacemos doble click sobre dicho rpm (o en su defecto, en una consola, urpmi nombreArchivoDriver.rpm) y se instalarán el driver y sus dependencias (deben estar en el mismo directorio todos). Una vez hecho esto, ya podemos ejecutar drakx11, seleccionar la familia de nuestra tarjeta gráfica, y listo, él hará el resto (la configuración a bajo nivel del servidor gráfico).

Driver oficial

Además de todo lo visto hasta ahora, los drivers privativos de ATI y NVidia están disponibles para bajar en forma de instalador en sus respectivas páginas. Sin embargo, si el driver está disponible empaquetado para Mandriva, ¿por qué usarlo? En principio, el único motivo por el que podría interesar usarlo es para tener la última versión disponible del driver. Por algún motivo que ignoro, los drivers en el repositorio non-free público no están todo lo actualizados que deberían. Sin embargo, los drivers en PLF sí están en la última versión disponible, y también utilizan DKMS, por lo que si es indispensable tener la versión más actualizada, con instalar la versión empaquetada por PLF es suficiente. De hecho, teniendo los repositorios configurados adecuadamente, al realizar las actualizaciones del sistema los paquetes más actuales sustituirán a sus versiones anteriores sin tener que realizar nosotros mismos la instalación explícitamente, incluso si el nuevo paquete es de PLF y el antiguo del repositorio non-free de Mandriva. Así pues, no hay necesidad de utilizar el binario oficial. Salvo excepciones muy concretas, cuando hay disponible un mismo programa, driver, biblioteca... en formato binario genérico o empaquetado explícitamente para Mandriva, lo mejor es utilizar el paquete para Mandriva. Y hasta aquí hemos llegado. Felicidades a quien aún siga despierto después de toda esta parrafada ;)

Como instalar programas en Linux

Introduccion

  1. Compilar Programas
  2. Instalar programas en Linux
  3. Paquetes
  4. Gestión de Paquetes o cómo se instala un programa (o paquete)
  5. Dependencias
  6. Sistemas de instalación de paquetes
  7. Aprender más
  8. Enlaces
Esta explicación puede que le sirva a los usuarios muy nuevos en Linux para entender mejor cómo se trabaja para instalar programas en Linux, y qué estás haciendo exactamente con "./configure, make, make install", por ejemplo: Lo que sigue es un fragmento de la respuesta que envié a un mail recibimos en una lista de la que soy suscriptor, a continuación la cuestión planteada, y después la explicación.
"intente compilar algunos programas, primero desempaquetando los archivos, y al teclear el comando ./configure, me pedía unas librerías algo de qt-mt >=3 2, y ahí quede, pero no me quise desilusionar, debo admitir que estoy acostumbradisimo a los .exe de windows, doble click y listo a aceptar todo nomás, a lo que quiero llegar es algún tutorial o algo parecido, porque tampoco se como ejecuto un programa instalado, etc."

Compilar programas

Lo que vos hiciste, al descomprimir el archivo que mencionás, es seguir un viejo mal consejo acerca de lo "fácil" que es instalar programas en Linux, solo haciendo "./configure, make, make install". Esto se refiere en realidad a compilar un programa desde el código fuente, algo sencillo si sos un programador (especializado en entornos Unix/Linux), pero no tan sencillo ni tan fácil de hacer si sos un usuario que recién empieza en esto de Linux. Seguí leyendo y fijáte como es esto de instalar programas en Linux en realidad.

Instalar programas en Linux

Comenzamos por la distro que usás, y a partir de ahí vemos como se hace en cada una en particular. Hablando en general para que tengas una idea de cómo se instalan programas en Linux, la cosa es así: Cuando instalás Windows, se instala solo el sistema operativo y algunas aplicaciones y herramientas; después tenés que instalar los programas. Esto ocurre porque Windows es propietario y los programas también; hay que comprarlos para poder usarlos. En Linux, cuando instalamos el S.O. también instalamos los programas que vamos a usar, en general la mayoría de las distribuciones modernas (Fedora, SuSE, Mandriva, etc.), brindan gran control sobre QUE se instala o no, aunque algunas prefieren lo contrario e instalan un conjunto preestablecido de programas, solo permitiendo una selección básica (oficina, multimedia, internet, etc.). Poder instalar el sistema de ese modo es la causa de que existan distribuciones que ocupen tantos CDs, ya que los programas (el 90% de los disponibles para Linux), son libres y se puede distribuirlos libremente (incluso aunque vendas los CDs). Linux en sí, el S.O. (kernel) más los drivers, ocupa poco más de 150 mb (a veces más, a veces menos), si sumás a esto componentes indispensables para el uso diario, como la interfaz gráfica y el soporte para impresoras, estaríamos en unos 250 mb aprox.; si a esto querés sumar un buen entorno de escritorio para correr, KDE por ejemplo, podemos llegar fácilmente a los 400/600 mb. (KDE se puede instalar modularmente según lo que necesites).

Paquetes

Claro que instalar programas al instalar el sistema operativo no es la costumbre, y Linux no te limita en absoluto, podés instalar/desinstalar programas ya habiendo instalado el sistema. Cuando en Linux hablamos de instalar un programa, en general nos referimos a "instalar un paquete", lo que implica que los programas vienen empaquetados en un archivo comprimido. Una aclaración, en Linux al igual que en Windows, los programas soportan bibliotecas de funciones compartidas. Es decir que si programamos en C++ tenemos ciertas librerías, si lo hacemos en C, otra, y así. Por esto los programas, las aplicaciones en sí, suelen ser bastante pequeñas en comparación con las de Windows (Kbs en Linux, Mbs en Win).

Gestión de Paquetes o cómo se instala un programa (o paquete)

Ok, viendo que tenemos varios miles de programas (comprimidos), disponibles en los CDs de Mandriva Linux (son 3 en la versión Download, y más en otras), por ejemplo. Surge de ahí la necesidad de tener algún tipo de sistema para gestionar la instalación/desinstalación rápida y eficaz de tanto software. No solo se trata de instalar, también hay que tener la posibilidad de buscarlos por nombre, leer alguna descripción acerca de qué hace el programa, buscar dentro de estas descripciones, etc. Bueno, para ello existen aplicaciones específicas, que en general, si vamos a la línea de comando, reducen la tarea de instalar un programa a esto: 
programa-instalador programa-a-instalar
Claro que asumimos muchas cosas, sabemos el nombre del programa, qué hace, etc. También existen interfaces gráficas, para por ejemplo realizar grandes instalaciones/desinstalaciones de modo amigable (instalar 30 programas de una sola vez, simplemente tildando checkboxes al lado del nombre, por ej.), y para lo más importante, buscar información (así podés buscar, por ejemplo, si querés algún visor de imágenes al estilo ACDsee, la cadena "visor" o "imágenes"), también podés buscar un programa que ya conocés por su nombre, para ver si está entre tus CDs (y no tener que insertar y buscar en 7 CDs a lo largo de miles de nombres). uf, era complicado eh, :-) en realidad esto es más extensivo como para explicarte bien nomás. Los procedimientos y el usar los programas de instalación se reducen a muy poca cosa en cuanto a complejidad (algo que usás muy seguido tiene que ser simple y rápido).

Dependencias

Algo de lo que vas a escuchar seguido es el tema de las "dependencias", que tiene que ver con lo que te expliqué antes sobre las librerías compartidas y también se aplica entre programas, por ejemplo: El programa A depende del programa B, y este a su vez de C (cada uno a su vez puede depender una o más librerías). Es decir que si quisieras instalar "A", tendrían que instalar todos los demás. Esto no sería simple. Bueno, así eran antes las cosas, cuando no había distribuciones de entre 1 y 11 CDs (Debian Woody ocupa 11 CDs en total, aunque solo es indispensable el CD 1). Así antes teníamos (tenemos aún en realidad), el comando "rpm" para instalar paquetes, el más extendido entre las distros, lo usan RedHat, Mandriva Linux, SuSE, etc., Las distros basadas en Debian tenían/tienen el "dpkg", etc. Esos comando permiten instalar paquetes como "A" individualmente, pero no resuelven las dependencias, para hacer esto se crearon los sistemas de instalación de paquetes, lo que mencioné al principio: algo que permite hacer simples las cosas.

Sistemas de instalación de paquetes

Estos sistemas de instalación de paquetes son lo que se usa en realidad al instalar algo hoy en día, hay varios y depende de cada distro cual usa, los más comunes son: Cabe aclarar que los paquetes tienen extensiones: rpm, deb: - los ".rpm" también son para yum y urpmi (no .debs); - apt-get tiene dos versiones, una que soporta rpms y otra para debs. Además existen otras extensiones y otros sistemas de instalación, menos populares y menos habituales. Cada distro tiene su interfaz gráfica para gestionar de modo gráfico los programas, y también hay interfaces gráficas independientes de las distribuciones.

Aprender más

Para aprender específicamente acerca de una distro en particular, por ejemplo Mandriva Linux, solo tenés que mirar en los manuales (fijáte al final para ver enlaces), algo que podés hacer siempre (pero siempre), en el sitio de la distribución y casi seguro que los CDs de tu distribución los incluyen también. Algo que podés hacer siempre también: buscar en Google: "como instalar programas en Mandriva Linux" por ejemplo (y no sigas leyendo si el consejo es hacer "./configure, make, make install" !!!)."

Enlaces:

Mail original de la lista SPX De aquí tomé la explicación que posteé arriba.

Cómo reinstalar GRUB con Mandriva después de que Windows lo borrase

A menudo pasa que los usuarios que aún no se deciden o no pueden dar el salto definitivo a Linux, tienen dos sistemas en sus máquinas (Mandriva Linux y Windows). Al reinstalar Windows (ya que casi siempre ésa es la solución para los problemas en Windows), éste borra el cargador de arranque (Grub). Mandriva sabe eso y tiene en su DVD (o CD) de instalación una opción para reparar ese problema que ocasiona Windows.
  1. Presionas F2 para pasar el menú a español:
  2. Seleccionas Sistema de rescate:
  3. Seleccionas Re-Install Boot Loader, que traducido sería Reinstalar Cargador de arranque:
Y listo, eso es todo.

Cómo reparar la base de datos de RPM

A veces sucede que por algún motivo la base de datos de RPM y por ende de URPMI se fastidia y ya no se puede usar. Si te pasa eso es fácil repararla, puedes intentarlo de cualquiera de estas dos formas:
  1. Ejecuta: 
    [dalfa@mdvspring ~]$ su
Contraseña:

[root@mdvspring dalfa]# rpm --rebuilddb
    El programa RPM ya trae una forma de reconstruir la base de datos simplemente con ejecutar rpm --rebuilddb.
  2. Ejecuta: 
    [dalfa@mdvspring ~]$ su
Contraseña:

[root@mdvspring dalfa]# cd /var/lib/rpm

[root@mdvspring rpm]# rm -rf ??db.00*

[root@mdvspring rpm]# rpm --rebuilddb
    Podría ser que el archivo de la base de datos esté tan arruinado que no se repare y se necesita borrarlo para crear uno nuevo.
Fuentes: http://blogdrake.net/node/8244#comment-37027 http://blogdrake.net/node/4769#comment-20715

Cómo saber si es un bug el no encontrar una aplicación en el menú

En ocasiones nos encontramos con que instalamos una aplicación, y no aparece ninguna entrada en el menú para ellas. ¿Por qué ocurre esto? ¿Es un comportamiento lógico? ¿Es un bug? A continuación, una pequeña explicación para que quienes se encuentren con este problema sepan qué es lo que deben hacer. Primero de todo, una pequeña introducción sobre los sistemas de menús. Hasta Mandriva 2006, se utilizaba el sistema de menús de Debian, que permitía lidiar de forma homogénea con los distintos formatos de menús utilizados por cada escritorio. Desde Mandriva 2007 en adelante, se migró del antiguo sistema de menús a Desktop Menu Specification, el estándar de freedesktop.org. Tanto KDE como GNOME como XFCE soportan el sistema de menús XDG (The X Desktop Group, nombre antiguo de freedesktop.org, pero que sigue usándose para algunas cosas como acortar nombres ;) ), además de mantener compatibilidad con sus antiguos sistemas de menús. Desconozco la compatibilidad de otros escritorios con el sistema de menús XDG. Para información más detallada sobre el sistema de menús, consultar el wiki de Mandriva: Development/Howto/XDGMenuSystem. Terminada la breve introducción, pasemos a ver los posibles problemas por los que una aplicación puede no aparecer en el menú y sus soluciones.

Estilos de menú

Primeramente, hay que considerar el estilo de menú de Mandriva, ya que según el estilo algunas aplicaciones podrían no mostrarse. Pueden escogerse 3 tipos de menú, a saber: Para escoger el estilo de menú se puede hacer desde consola utilizando drakmenustyle, o desde el propio menú (la ubicación de la entrada dependerá, lógicamente, del estilo de menú que se esté usando). Los estilos pueden establecerse independientemente para cada usuario, o de forma global para el sistema (si se ejecuta desde consola como root, o bien desde el Centro de control de Mandriva (drakconf)). En el menú original de cada escritorio podrían no aparecer todas las aplicaciones. El motivo, si no me equivoco, es que, aunque ambos utilizan el sistema de menús de freedesktop.org y también tienen soporte para la versión antigua de su sistema de menús, para lo que no tienen soporte es para la versión del sistema de menús antigua cada uno del otro. Es decir, KDE no ve las aplicaciones que usan el sistema de menús antiguo de GNOME, y viceversa (repito que no estoy seguro 100% de esto). Pero, ¿no se supone que Mandriva había migrado al sistema de menús de freedesktop.org? Sí, y no. La mayor parte de los paquetes están migrados al nuevo sistema de menús. Peeero... en toda migración quedan flecos y cosas que pulir ;) Por tanto, puede darse el caso de que si estás utilizando uno de los estilos de menú nativos, no veas aplicaciones que sí verías con otros estilos. No obstante, como veremos más adelante podemos considerar esto un bug de la aplicación. El estilo de menú Discovery por su parte es una versión reducida del menú que incluye las aplicaciones más comunes. Si no me equivoco, no se muestran todas las aplicaciones, aunque en este caso sí es deliberado. Finalmente, queda el estilo de menú Mandriva (mi preferido, y francamente una de las cosas que más me gustan de Mandriva). El estilo de menú de Mandriva muestra tanto aplicaciones que usan el sistema de menús de freedesktop.org, como las que usan el de KDE, como las que usan el de GNOME (y supongo que también tiene soporte para los demás tipos de menús, que seguramente alguno más habrá). Por tanto, a la hora de investigar posibles problemas con el sistema de menús, lo mejor es utilizar este estilo.

Entradas de menú ocultas

Si una vez que tenemos configurado el estilo de menú de Mandriva la aplicación que queremos sigue sin aparecer, puede ser sencillamente porque la entrada de dicha aplicación está oculta. ¿Y cómo puedo saber si está oculta? No sé si hay alguna forma más sencilla para hacer esto, pero la que yo conozco es comprobando los ficheros desktop. Los ficheros .desktop son una especificación de freedesktop.org que permite describir cómo se deben lanzar las aplicaciones, cómo se muestran en el menú, su icono... El formato del fichero desktop es muy sencillo, formado simplemente por una serie de propiedades y un valor asignado: 
propiedad1=valor1
propiedad2=valor2
...
Una de las propiedades disponibles es Hidden. Si el valor de esta propiedad es true, la entrada del menú estará oculta. Del mismo modo, también existe la propiedad OnlyShowIn, que indica en qué escritorios debe mostrarse la entrada del menú. Desde cualquier otro escritorio no incluido en sus valores, la entrada estará oculta. En estos dos últimos casos cabe plantearse si esas propiedades son correctas, o si están de más y se trata de un bug. Y lógicamente, otro motivo por el que una aplicación no se muestra en el menú es porque es una aplicación de consola (aunque algunas también pueden mostrarse haciendo que se lance una consola cuando se ejecutan).

Buscar ficheros desktop

En el apartado anterior consideré que se miraba en el fichero .desktop de la aplicación las propiedades para saber si tienen un valor correcto. Pero, ¿cómo puedo saber dónde están los ficheros desktop de la aplicación? Los ficheros desktop vienen incluidos en los paquetes que contienen las aplicaciones. Así que la forma más fácil de buscar un fichero .desktop es buscarlo utilizando desde una consola el práctico urpmq combinado con el no menos útil grep. Pero vayamos poco a poco, ¿qué es cada cosa y cómo me pueden servir para buscar archivos .desktop en paquetes? urpmq es un complemento de urpmi que permite buscar en la base de datos de paquetes de éste, y mostrar información de los paquetes. Y entre sus múltiples posibilidades, está la de mostrar la lista de ficheros que forman un paquete. Para ello, tenemos que hacer urpmq -l nombrePaquete-version. Utilizo nombrePaquete-version en lugar de nombrePaquete a secas ya que si hay más de un paquete con el mismo nombre (por ejemplo, debido a actualizaciones o backports), mostraría los paquetes de todas las versiones. Hay que tener en cuenta que esto funciona sólo cuando se usan ficheros hdlist (que contienen toda la información de un repositorio), pero no con los synthesis (que sólo contienen información de dependencias, por lo que son mucho más pequeños pero también pierden funcionalidad). Por su parte, grep permite buscar una cadena dentro de un texto y mostrarla. Dado que urpmq -l nombrePaquete-version muestra todos los ficheros de un paquete, y sólo nos interesan los .desktop, redirigimos la salida de urpmq a grep mediante una tubería de la siguiente manera: 
urpmq -l nombrePaquete-version | grep .desktop
Según la salida que nos muestre, nos encontraremos ante un caso u otro.

Cuando no hay ficheros desktop

Un caso no muy común, pero que puede ocurrir (sobretodo con aplicaciones que no son de un escritorio concreto, como por ejemplo juegos) es que el paquete no tenga ningún fichero desktop. En este caso generalmente podemos considerar que nos encontramos ante un bug tanto de la aplicación del paquete en sí, como de Mandriva. En los casos en los que una aplicación carece de fichero desktop, Mandriva suele añadir un fichero desktop específico que permite a la aplicación mostrarse en el menú. Ejemplos de esto pueden verse en /usr/share/applications. Los archivos desktop que comienzan por mandriva- son específicos de la distribución y no están en el paquete original (como por ejemplo pasa con foobillard). Si una aplicación que debería aparecer en el menú no tiene fichero desktop de ningún tipo, y por tanto no aparece en el menú, es un bug de Mandriva por no haber añadido un fichero desktop específico. Pero también es un bug del propio programa, ya que lo lógico es que todos los programas migren al sistema de ficheros desktop de freedesktop.org, independientemente de si son de un escritorio, otro, o ninguno en concreto.

Cuando hay varios ficheros desktop

Puede darse el caso de que un paquete tenga más de un fichero desktop, ya que estos se utilizan para más cosas que para entradas de menú. Por ejemplo, los KParts de KDE (la tecnología que permite incrustar componentes, por poner un ejemplo para ver imágenes directamente en Konqueror sin abrir un programa externo) tienen ficheros desktop propios. ¿Cómo discernir la paja del grano? Siendo breves, los únicos que nos interesan son aquellos que estén en los siguientes directorios (y sus subdirectorios): En esencia, podemos ignorar los demás ficheros desktop para el propósito que nos ocupa, que es encontrar fallos a la hora de mostrar aplicaciones en el menú. Al igual que en el caso anterior, tampoco es muy común que, una vez hecha la criba, tengamos más de un fichero desktop relevante. Pero puede darse el caso, y que ninguna entrada se muestre en el menú, como por ejemplo pasa con el paquete para KDissert. El paquete contiene un fichero desktop en /usr/share/applications/kde/ y otro en /usr/share/applnk/Utilites/. El problema es que no son iguales, sino que el segundo fichero contiene una categoría de Mandriva adicional a las que contiene el primero (en el siguiente apartado se verán más a fondo las categorías). Parece ser que, al ser distintas las categorías para una misma aplicación, el pobre sistema de menús se trastorna y no muestra ninguna entrada. La solución es simple: añadir la categoría de Mandriva adicional también en el primer fichero desktop, de forma que ambos archivos sean iguales. En este caso, en el que la categoría adicional es de Mandriva, nos encontramos con un bug puramente de Mandriva (ya que la modificación de los ficheros desktop fue cosa de Mandriva). En el caso de KDissert, es el siguiente: KDissert isn't shown in KDE menu. El hecho de que el paquete original tenga dos ficheros desktop puede verse también como un bug, ya que lo correcto sería seguir únicamente una especificación. No obstante, esto puede deberse a cuestiones como la compatibilidad hacia atrás con versiones más antiguas de KDE.

Cuando hay un único fichero desktop

Ánimo, que ya estamos acabando ;) Cuando nos encontramos con un único fichero desktop, pueden ocurrir dos cosas: que esté en el directorio o subdirectorios del menú de freedesktop.org (/usr/share/applications) o no. Si no está en dicho directorio, es un bug de la aplicación, por lo mismo que ocurría cuando no había ningún fichero desktop: las aplicaciones deberían seguir el estándar de freedesktop.org. También es conveniente enviar un bug a Mandriva con el fin de que realicen una versión actualizada del paquete que corrija el problema mientras sale la nueva versión de la aplicación. Esto podría ser la causa de no ver algunas aplicaciones si se utiliza el estilo de menú de KDE o de GNOME. No obstante, cuando se utiliza el estilo de menú de Mandriva, la causa es otra (ya que, recordemos, el estilo de menú de Mandriva soportaba los directorios del sistema de menú de freedesktop.org, de KDE y de GNOME). Llegados a este punto, la única causa restante del problema serían (tanto para ficheros desktop en /usr/share/applications como en los directorios de KDE y GNOME) las categorías del fichero desktop. ¿Y qué son las categorías? Ni más ni menos que el tipo de aplicación: juego, multimedia, administración... Existen una serie de categorías generales, y una serie de categorías adicionales que complementan a las generales. Además, existen categorías específicas, como X-KDE-More o X-MandrivaLinux-MoreApplications-Games-Strategy. Según las categorías a las que pertenece un fichero desktop, la entrada se muestra en el menú en un lugar o en otro (se puede cambiar qué categorías están asociadas a qué estructura del menú, pero está fuera del ámbito de este documento, aparte de que no domino el tema ;) ). El problema surge cuando las categorías incluidas en el fichero no son válidas (por ejemplo, Wrong category in desktop file prevents trackballs from showing in the menu), tienen un formato inválido (por ejemplo, falta el ; tras la última categoría, o están mal escritas: Mispelled Mandriva category in desktop file prevents knotes from showing in the menu) o simplemente no hay sección de categorías (por ejemplo, TEG doesn't show in KDE menu o Missed category in desktop file). En todos estos casos debe informarse a Mandriva del problema, y en algunos casos también a los desarrolladores de la aplicación implicada (cuando en el sistema de control de versiones o en el paquete de código fuente de la aplicación el fichero desktop contenga fallos en las categorías).

Reportando bugs

Finalmente y para terminar, hay que tener en cuenta que los bugs encontrados es muy importante que sean reportados, ya que si no se informa de ellos, no serán arreglados ;) Además, es una forma sencilla y práctica de colaborar con el software libre :) Para más información sobre cómo enviar bugs en Mandriva, lee ¿Encontraste un error en Mandriva? Utiliza Bugzilla / Drakbug para comunicarlo. Para enviar bugs a programas concretos, dependerá del programa en cuestión, así que lo mejor que puedes hacer es visitar la página web y buscar por ahí. En caso de que el inglés sea un problema, siempre puedes comentarlo en el foro de bugs, y fijo que alguien te podrá echar una mano con el idioma.

Descubriendo Mandriva Linux (introducción para novatos totales)

Esta serie posteos está dirigida a todos aquellos que acaban de llegar al universo de Linux y al planeta de Mandriva y su luna Blogdrake en particular. Trata de ser una especie de "primeros pasos" muy resumido, con enlaces a mucha información que puede llegar a abrumar, pero que espero te sirva para tener un sistema funcional y mínimamente personalizado a tu gusto en poco tiempo. Sin volverte loco con un montón de conceptos y terminología que de entrada te sonará a mandarín clásico, pero que por asociación y poco a poco, irás descubriendo que no es tan enrevesado, oscuro y críptico como parece. El principio: ¿Por donde empiezo? Lo primero que debes decidir es qué edición de Mandriva descargar e instalar en tu ordenador. Mandriva (la empresa) ofrece diferentes ediciones de su distribución Linux. Algunas son de pago, otras no, unas llevan software propietario, otras únicamente software libre... Lo ideal sería que decidieses a priori qué edición de Mandriva vas a instalarte: Mandriva ONE: Es una edición en un único CD, que incluye un sistema gestor de escritorio, aplicaciones de ofimática, herramientas de internet, programas multimedia... de todo un poco. También incluye los tan cacareados escritorios 3D (compiz, beryl y metisse), así como los drivers propietarios para mucho hardware (tarjetas de vídeo, wireless...). Las Mandriva ONE se subdividen en dos, en función del escritorio que vayas a usar. KDE y Gnome. Atención: No son excluyentes, y una vez instalado, puedes instalar KDE en una ONE Gnome y viceversa. Pero eso lo veremos más adelante. Sigue este enlace para ver una tabla comparativa del software incluído en cada versión de Mandriva ONE (y con el software incluído en cierto sistema operativo propietario) Un detalle interesantísimo de las ediciones ONE de Mandriva es que vienen en formato Live-CD. Esto es, puedes arrancar el sistema directamente desde el CD y tenerlo en marcha sin llevar a cabo ninguna instalación en disco duro. Ello te permite evaluar el sistema en general y despues decidirte a instalarlo con un simple dobleclick en un icono que aparecerá en el escritorio(*) Sigue este enlace para ver cómo y desde dónde descargar la versión ONE (tanto KDE como Gnome). Mandriva FREE En el tiempo que llevo en esto del software libre, Linux y Mandriva, me he dado cuenta de que hay mucha confusión con el término Free que acompaña a muchos productos informáticos. Vamos a dejarlo claro desde el primer párrafo: La edición Free de Mandriva Linux es "free" en las dos acepciones. "Free" de libre y "Free" de gratis. La edición es excluyente únicamente en los paquetes incluídos en lo que software libre se refiere. No hay ni una sóla pieza de software propietario. Ni drivers, ni otros programas que no sean 100% GPL. ¿Quiere decir esto que no vas a poder usar software propietario con Mandriva Free? Rotundamente NO. Únicamente implica que no podrás instalarlo del DVD...básicamente porque no está ahí. No sé donde leí que es la edición de Mandriva que Richard Stallman se instalaría. La edición Free de Mandriva es una distribución en DVD con -literalmente- miles de aplicaciones libres. Y pronto descubrirás que difícilmente no encontrarás ahí algo que te haga falta (siempre que sea SL, claro). Si quieres usar software propietario con esta edición de Mandriva, únicamente debes configurar los repositiorios (tranquilidad, suena más chungo de lo que es) y descargarte todo el software que necesites. Sigue este enlace para conocer más a fondo todo lo que Mandriva Free puede ofrecer, y éste otro para saber cómo y de dónde descargar Mandriva Free. Versiones de pago Más confusión y controversia. Mandriva (la empresa), ofrece versiones de pago de su distribución Linux. Para el usuario doméstico son las ediciones Discovery, Powerpack y Powerpack+. Estas ediciones están a disposición en descarga (pagas, descargas, grabas y listo), y en caja (pagas, te lo envían y listos). La versión en caja incluye un montón de documentación sobre Mandriva. El sistema y sus programas. ¿Qué diferencias hay entre la edición Free y las de pago? Las versiones de pago incluyen software propietario, comercial o de cualquier otra índole cuya licencia impida incluirlo en una versión 100% GPL. Los drivers propietarios de tarjetas gráficas, el reproductor flash, etc. son ejemplos del software que viene incluído. Pero atención: esto no significa que las ediciones Free no puedan usar este software. Está a disposición de todos los usuarios de Mandriva a través de los repositorios, excepto el software de pago, claro está. Pero ése hay que pagarlo sí o sí, en el caso de que quieras usarlo. El rango de precios va desde los 44€ de la edición descargable de Discovery a los 199€ de la versión en caja de la edición Powerpack+. Sigue éste enlace para ver las distintas ediciones de pago y sus precios. Una solución para disponer de estas versiones de pago es hacerte socio del Club Mandriva. La opción Silver da acceso a distintas ediciones descargables de pago, aparte de descuentos en la tienda, etc. por 120€ anuales. En el caso de los usuarios residentes en América Latina, los precios descienden hasta un tercio, y podeis iniciar vuestra suscripción enviando un correo a webmaster@mandrivaclub.com. ¿Lioso? No tanto. Además, si tenemos en cuenta el funcionamiento de las distribuciones Linux, en esencia no importa qué edición Mandriva descargues, puesto que el software que no viene incluído en tu edición lo tendrás disponible para descarga a través de los repositorios. Pero para ello, deberás instalar Mandriva en tu ordenador antes. Vamos a ello. En próximas entregas: -Instalando Mandriva Linux desde un Live-CD. -Repositorios: de 0 a 1000 en cuatro clicks.

Documentacion Oficial de Mandriva Linux [En construccion]

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

Instalación de Oracle 8.0.5 para Linux

Autor: Luis M . Cruz, lcruzva@clientes.unicaja.es y Angel Carrasco karrasko@arrakis.es

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

1. Introducción

2. Copyright

3. Preinstalación

4. Instalación

5. Postinstalación

6. Anexo: El INSFLUG

1. Introducción

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.

2. Copyright

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.

3. Preinstalación

Esta es la parte principal para que funcione todo. Aquí creará todos los pilares para que pueda usted instalar Oracle.

3.1 Requerimientos técnicos.

En el apartado hardware:
  • 32 MB de RAM, en caso de que haga cargas elevadas se requerirá incluso 128 MB
  • SWAP, aproximadamente el triple de la memoria RAM instalada
  • 400 MB de disco duro para la instalación
  • Al menos unas 150 MB de disco duro por defecto por cada base de datos Oracle creará alguna base de datos por defecto
En el apartado software:
  • Al menos el Kernel 2.0.34
  • GLIBC 2.0.7, incluida en Red Hat 5.2 y superiores o Debian 2.0
  • JDBC JDK 1.0.2 ó 1.1.1
  • ProC/C++ gcc 2.7.2.3 o superior
  • Tcl8.0

3.2 Configuración del Kernel

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:
  • SHMMAX -> 0xFFFFFFFF
  • SHMMIN -> 1
  • SHMMNI -> 100
  • SHMSEG -> 10
El segundo sería /usr/src/linux/include/linux/sem.h
  • SEMMNS -> 200
  • SEMMNI -> 70
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

3.4 Puntos de montaje

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

4. Instalación

Procederá a la instalación de Oracle 8.0.5. Para lo cual debe seguir los pasos siguientes:

4.1 Montaje del CD-ROM

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

4.2 Crear el fichero oratab

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.

4.3 Ejecución de orainst

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

5. Postinstalación

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.

6. Anexo: El INSFLUG

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

BogoMIPS mini-COMO

Wim C.A. van Dorst baron@clifton.hobby.nl
Traducido por Juan Carlos Durán García jcdg@hotmail.com

16-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 10. Nota sobre la traducción al español 11. Anexo: El INSFLUG

1. Nota del traductor:

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.

2. Qué son los 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:
  • Es moderadamente útil para la depuración y para comprobar que las cachés y el botón de turbo funcionan; y
  • A Linus le encanta reírse un poco cuando ve a la gente confundida en las news.
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 {} \;
)

3. Cómo estimar los BogoMIPS

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)
  • Obsérvese que el bucle de cálculo de los BogoMIPS no hace uso del paralelismo de varios procesadores, como el Intel Pentium y el Alpha 21164.
  • Obsérvese que el bucle de cálculo de los BogoMIPS es similar pero no igual en los procesadores no-Intel.

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:
  • Para comprobar si está dentro del margen propio para el procesador particular, su frecuencia de reloj y el caché potencialmente presente. Los sistemas 486 (y sus variaciones) son particularmente propensos a padecer configuraciones defectuosas de la caché de la RAM "write-back" Escritura retardada que afectan los BogoMIPS, frente a "write-trough" escritura inmediata que van bien, botones de turbo, falsas cachés emuladas por la BIOS, y ese tipo de cosas relacionadas con la caché y la frecuencia.
  • Para ver si "su sistema es mejor que el mío". Por supuesto esto es completamente erróneo, nada fiable, infundado y absolutamente inútil, pero todas las medidas de rendimiento padecen este mismo problema. Así que ¿por qué no usarlo? Esta estupidez inherente nunca ha evitado que la gente use los índices de rendimiento, ¿verdad? :-)

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>

9.2 Sistemas 386 normales

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>

9.4 Sistemas 486 de Cyrix/IBM

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>

9.5 Sistemas 486 normales

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