Rufus FAQs – Preguntas Frecuentes

Esta es una recopilación de las principales preguntas frecuentes que se hacen los usuarios de Rufus para PC. Si tienes alguna duda, aquí puedes encontrar toda la información que hemos ido recopilando a lo largo de los años de los diferentes usuarios de este programa. En caso de no encontrar la tuya, siempre puedes escribirnos al email que tenemos habilitado en nuestra página de contacto.

Contents

¿Quiénes son ustedes? ¿Quién o qué es Akeo?

Soy un desarrollador de software no afiliado que también es un entusiasta del software libre y colaborador de varios proyectos de código abierto.

Akeo es el nombre de mi empresa, pero en realidad es una operación de una sola persona que llevo a cabo en mi tiempo libre, así que por favor no espere que tenga el mismo nivel de recursos que Microsoft, Google o Apple cuando se trata de desarrollo y soporte…

Ah, y por cierto, Akeo es el nombre de un pequeño lago que sólo se ve desde la parte superior de Muckish, pero eso no te importa, ¿verdad?…

¿Por qué el desarrollo de Rufus no es más rápido?

Unas cuantas razones:

  1. Tengo un trabajo regular de 9 a 5, en una compañía que no es Akeo, así que todas mis actividades de desarrollo de software público tienen que ocurrir en mi limitado tiempo libre.
  2. Rufus es sólo uno de los muchos proyectos Open Source en los que intento participar.
  3. Debido a su popularidad, paso bastante tiempo teniendo que responder a consultas por correo electrónico o ocupándome del seguimiento de problemas. Esto le quita tiempo al desarrollo.

¿Por qué creaste Rufus USB?

Principalmente porque descubrí que realmente no soporto el software propietario y me cansé de ver a todo el mundo usar la confiable, aunque antigua y limitada, utilidad de formato HPUSBFW. La ingeniería inversa de esa herramienta para crear un clon de Software Libre parecía un reto interesante, así que me decidí por ella. Para información adicional de fondo, vea aquí.

¿Por qué no vendes a Rufus?

Déjame preguntarte esto entonces: ¿Pagarías 0,99$ por una utilidad que simplemente crea USBs de arranque?

¿O simplemente elegirías una de las muchas alternativas gratuitas?

Diablos, ni siquiera yo pagaría 0,99$ por esto, a pesar de ser muy consciente del coste asociado a su desarrollo.

Así que, incluso si pudiera intentar sacar provecho del éxito de Rufus, creo que sería mejor intentar beneficiar a millones de usuarios, proporcionando una aplicación gratuita, en lugar de sólo unos pocos miles con una de pago.

Además, con el código siendo Software Libre (lo cual es una elección muy deliberada ya que Rufus no sería tan bueno como lo es si fuera código cerrado, ¡debido a su capacidad para aprovechar el gran trabajo de otros!), cualquiera podría recompilar y distribuir la misma versión de forma gratuita.

¿Por qué no puedes simplemente añadir la característica que quiero?

También conocida como: “Eres un desarrollador después de todo – ¡no debería ser tan difícil!”

Bueno, no hay una buena manera de responder a esa pregunta sin sonar como un condescendiente, así que seré brutalmente honesto:

Como ya he señalado, no me pagan por desarrollar a Rufus.

Así que cada vez que invierto en el desarrollo de Rufus es tiempo que me cuesta y que tengo que compensar con otra fuente. Por lo tanto, como no puedo pasar mis días en él, tengo que priorizar las características y correcciones que probablemente beneficien a un mayor número de personas.

Como tal, si el problema es que no puedes arrancar en tu máquina específica (mientras que la máquina de todos los demás parece estar bien) o estás usando una imagen ISO oscura, o quieres resolver un problema específico de tu uso, o estás experimentando un problema específico bajo condiciones que se espera que muy pocas personas cumplan, o quieres una característica que, cuando todo esté ponderado (en lugar de tu propia visión parcial de que “¡Por supuesto, todo el mundo querrá eso!”), no va a beneficiar a muchos usuarios después de todo, es probable que empuje su petición al final de la lista de lo que estoy planeando trabajar a continuación, si es que lo hago.

Además, y esto es importante, por favor, date cuenta de que no es porque quieras realizar una operación que esté vagamente relacionada con lo que hace Rufus, que deberías pedir que Rufus la haga. El objetivo de Rufus es crear unidades USB de arranque, y eso es todo. Cualquier otra cosa, como la duplicación de una parte del disco, o la evaluación comparativa, o el soporte de software específico no ampliamente utilizado, o lo que hacen otras utilidades, está fuera del alcance.

Esto es sólo una reformulación de uno de los puntos ya mencionados anteriormente, pero me temo que esto debe ser recalcado: MUCHAS de las peticiones que recibo para Rufus podrían ser calificadas como bastante egoístas. En otras palabras, sólo se solicitan porque alguien “se metió en esta situación específica una vez, donde habría sido genial si Rufus pudiera hacer X” o “pensó que sería bueno que Rufus pudiera hacer X”, mientras que no se espera lo mismo de un número suficientemente grande de usuarios de Rufus (que es lo único que importa a la hora de decidir si una característica debe ser añadida a Rufus o no). Uno de los pasos cruciales, que la gente parece perderse al solicitar una característica, es hacerse las siguientes preguntas cruciales:

¿Cuánta gente estará realmente en una situación en la que la característica que solicito sea útil, especialmente si se está avanzando (es decir, teniendo en cuenta que los usuarios están constantemente actualizando el hardware, las nuevas versiones de los sistemas operativos, las unidades flash USB más grandes, etc.)?

¿Qué tan útil sería esa característica en ese caso? ¿Sería una necesidad (es decir, los usuarios se verán perjudicados si intentan llevar a cabo su operación sin ella) o simplemente una mejora estética o agradable?

Rufus NO está diseñado como una aplicación Sysadmin/Power de fácil uso. En su lugar, está diseñado para que las personas puedan realizar una instalación única de un sistema operativo en un solo sistema de destino utilizando una sola unidad. Por lo tanto, tengo muy poco interés en añadir características que se desvíen de ese objetivo porque introduciría problemas importantes, como la mantenibilidad del código, las pruebas, el soporte, etc. Y si bien es cierto que todavía puede encontrar algunas características avanzadas aquí y allá, éstas suelen estar ocultas como modos de engaño, y casi ninguna de ellas se derivan de querer resolver una petición específica de un usuario…

No puedo enfatizar eso lo suficiente: Desarrollar no es sólo añadir código!

Para darte una idea, estimo que, en este momento, paso más del 33% de mi tiempo de “desarrollo” asignado en actividades no relacionadas con el código, tales como responder correos electrónicos sobre características de código existentes, pruebas de regresión, para asegurarme de que una característica no se ha roto entre revisiones, y así sucesivamente.

De hecho, te daré la regla de Pete sobre ese tema: Durante la vida de un proyecto de Código Abierto, sólo el 10 por ciento del tiempo dedicado a añadir una característica se dedicará a codificarla. El otro 90 por ciento se dedicará a apoyar esa característica. Por lo tanto, si no planea pasar mucho más tiempo apoyando una característica, que lo que planea agregar el código para ella, ¡no debería agregar la característica en primer lugar!

Lo que todo esto significa es que, siempre que me pida que añada una característica o que arregle un problema que sólo usted parece estar experimentando, intentaré estimar cuánto tiempo costaría soportarla fuera del cambio inmediato de código, y dependiendo del resultado de esa estimación, las probabilidades de que el cambio sea “rápido y fácil” pueden no estar realmente tan a su favor como usted cree…

Desarrollar es difícil, e incluso fuera de apoyar una característica, ¡añadir el código toma mucho más tiempo de lo que usted piensa!

Lo que esto significa es que incluso tu “¿Qué tan difícil puede ser agregar <insertar una característica aparentemente elemental aquí> a la aplicación?” podría requerir días de trabajo duro, sólo para codificar la característica… y toda una vida apoyando a sus usuarios. Esto es especialmente cierto si se trata de algo que requiere que la interfaz de usuario sea alterada.

Por supuesto, dicho esto, recuerda que Rufus es 100% de código abierto. Así que si realmente quieres una característica, puedes intentar encontrar un programador comprensivo (o incluso mejor, desarrollar tus propios conocimientos de programación) para modificar el código y luego enviar un parche para su revisión.

¿Cuánta gente usa Rufus?

A partir del 2018.01.01, Rufus se descarga más de 3 millones de veces al mes (!).
En total, estimo que, desde que Rufus fue lanzado por primera vez en 2012, ha sido utilizado por más de 100 millones de personas, y contando…

Características existentes

¿Cuál es la diferencia entre la versión portátil y la regular?

En primer lugar, creo que necesito definir qué es la portabilidad, porque mucha gente (incluyendo Wikipedia) utiliza una definición errónea, y no entiende en absoluto de qué se trata realmente una aplicación portátil.

Una aplicación portátil es una aplicación que te da la capacidad de llevar y preservar tu configuración cuando te mueves de un ordenador a otro.

Eso es todo. Eso es todo lo que hace una aplicación portátil.

Por lo tanto, si usted espera que la portabilidad implique algo acerca de NO escribir en el registro de Windows, o no venir con un instalador, está muy equivocado. La mayoría de las veces, ser portátil significa que la aplicación escribirá sus configuraciones en un archivo de texto (como un archivo .ini en Windows) que puede llevar consigo con el software, mientras se mueve de una computadora a otra, en lugar del registro, y esta puede ser la razón por la que muchas personas confunden “portátil” con “no escribir en el registro, nunca” en Windows, pero en realidad no se hace ninguna promesa de una aplicación portátil de buena fe de que dejará el registro intacto.

Y así, una vez aclarado esto, puedo explicar que la versión regular de Rufus ya califica como una aplicación portátil porque, si por casualidad tienes un rufus.ini en el mismo directorio que tu ejecutable de Rufus (aunque sea un archivo vacío), entonces Rufus leerá y escribirá sus ajustes, como el idioma en el que quieres ejecutar la aplicación, o las otras opciones que se conservan entre sesiones, en ese archivo, y si copias tanto tu rufus.ini como el ejecutable de Rufus a otro ordenador, verás que tus ajustes se han conservado del ordenador anterior, por lo tanto “portátil”. Y en esta etapa, también tengo que destacar que, incluso cuando Rufus se ejecuta en modo portátil, tu registro será modificado, ya que esto NO es de lo que se trata la portabilidad.

Entonces, ¿por qué proporcionar una versión portátil en absoluto, dices? Bueno, esto nos lleva a la ÚNICA diferencia que tiene la versión “portable” de Rufus con la “regular”, que es que la versión “portable” creará un rufus.ini por defecto (para que no tengas que hacerlo tú mismo, si quieres usar Rufus en modo portable), mientras que la versión regular no lo hace. Eso es realmente todo lo que hay que hacer!

¿Qué idiomas están soportados nativamente por Rufus?

La siguiente tabla enumera los idiomas que Rufus admite de forma nativa.

La decisión de incluir un idioma específico siguió a lo que yo (y otros) considero que son los 35 idiomas más frecuentes, y en esta etapa, no hay planes para proporcionar ninguna otra traducción (para más información sobre esto, véase más abajo).

Sólo puedo expresar mi más sincero agradecimiento a todas las personas que contribuyeron a estas traducciones!

  • Árabe
  • Búlgaro
  • Chino (Simplificado)
  • Chino (Tradicional)
  • Croata
  • Checo
  • Danés
  • Holandés
  • Inglés
  • Finlandés
  • Francés
  • Alemán
  • Griego
  • Hebreo
  • Húngaro
  • Indonesio
  • Italiano
  • Japonés
  • Coreano
  • Letón
  • Lituano
  • Malayo
  • Noruego
  • Persa
  • Polaco
  • Portugués (Brasil)
  • Portugués (Portugal)
  • Rumano
  • Ruso
  • Serbio (latín)
  • Eslovaco
  • Esloveno
  • Español
  • Sueco
  • Tailandés
  • Turco
  • Ucraniano
  • Vietnamita

¿Qué pasa con los idiomas que no están en la lista anterior?

Aunque originalmente planeé dar soporte a los idiomas que no están listados arriba a través de archivos ‘loc’ adicionales descargables, debido a la necesidad de mantener las traducciones actualizadas, así como el tiempo y el esfuerzo que este mantenimiento requiere efectivamente, he decidido que multiplicar el soporte a los idiomas más allá de los mencionados arriba no era el mejor interés de nadie (ya que quitaría un tiempo precioso para arreglar problemas o añadir nuevas características).

Ahora bien, esto no significa que no puedas crear y proporcionar tu propio ‘rufus.loc’, para los idiomas adicionales, ya que Rufus utilizará felizmente cualquier archivo ‘rufus.loc’ que resida en el mismo directorio de la aplicación, para proporcionar traducciones adicionales. Sólo que, si lo haces, tendrás que encargarte de la distribución y el soporte de estos archivos no oficiales tú mismo.

¿Por qué no se traducen los mensajes de registro?

El propósito principal del registro es ayudarme a mí, el desarrollador, a solucionar los problemas de la aplicación cuando los usuarios encuentran un problema. Y para poder hacerlo, necesito ser capaz de entender lo que aparece en él.

Por lo tanto, quiero que todos los mensajes de registro estén siempre en inglés. De lo contrario, ¡no podré ayudar a los usuarios que no usen Rufus en inglés!
Si eres un usuario avanzado, puedes, por supuesto, utilizar el registro para encontrar información adicional con respecto a lo que está haciendo Rufus, pero, debido a que esto no está dirigido a los usuarios regulares, estos datos no están destinados a ser localizados y se espera que entiendas el inglés si quieres utilizar el registro.

¿Cómo es que la versión portátil y la regular son binarias idénticas?

Esto se debe a que la forma en que Rufus detecta si debe ejecutarse en modo portátil o regular es comprobando el nombre de archivo del ejecutable. La forma en que funciona es así: si el nombre del archivo contiene la letra p, entonces el código se ejecutará en modo portátil. Y si no hay p, entonces se usa el modo regular. De hecho, en el servidor web, la descarga de la versión portátil es sólo un enlace simbólico a la versión regular, con una p añadida al nombre, así que por supuesto los binarios siempre serán idénticos.

Pero no hay nada de extravagante o misterioso en este método – software como Busybox ha estado haciendo esto durante años y no deberías asustarte, o decirme que hay un problema con las descargas, ya que el tamaño y el contenido de la versión portátil y la versión regular de Rufus son exactamente los mismos. Existen muchas maneras de hacer que un mismo ejecutable se comporte de forma completamente diferente, a través de factores externos, como el nombre del archivo…

¿Cómo creo una unidad VHD para usar con Rufus?

Crear y usar un VHD desde cero

Desde la versión 1.4.7, Rufus puede utilizarse con discos duros virtuales de Microsoft (VHD o VHDX). Lo que hagas con un VHD depende de ti (no voy a dar ningún consejo al respecto), pero, ya que a veces pido a las personas que tienen un problema que también prueben con un VHD, aquí está cómo puedes crear uno para utilizarlo con Rufus, siempre que estés utilizando Windows 7 o posterior:

Abre la Gestión de Ordenadores, yendo al Panel de Control → Herramientas Administrativas. Ten en cuenta que si no ves Herramientas administrativas en el Panel de control, es posible que primero tengas que hacer clic en la categoría Sistema y seguridad.

En Administración de equipos, haga clic en Administración de discos en la columna izquierda (bajo Almacenamiento) y espere a que Windows llene la información sobre los discos.

Haga clic en un disco (1) y, a continuación, haga clic con el botón secundario en Administración de discos (2). Ahora debería poder seleccionar Crear VHD en el menú. Tenga en cuenta que hasta que no seleccione un disco en el lado derecho, no verá la opción Crear VHD.

Crear el VHD por:

  • Escriba la ruta de la ubicación en la que desea que Windows cree el archivo VHD. O puede utilizar el botón Examinar. No es necesario que el archivo exista – será creado por Windows.
  • Seleccionar el tamaño del disco virtual que desea que Windows cree
  • (Opcional) Le dice a Windows que amplíe el tamaño de forma dinámica. O puede usar un tamaño fijo, pero en este caso, Windows necesitará asignar el tamaño que especificó en el paso 2 de inmediato, lo que significa que si elige crear un VHD de 8 GB, Windows asignará 8 GB de espacio en disco para él, incluso si no hay datos en el VHD.

Una vez que haya completado lo anterior, Windows mostrará el VHD como si fuera un disco real, en el Administrador de discos.

El VHD también estará disponible en Rufus.

Ten en cuenta que el VHD se desmontará al reiniciar. Si quieres volver a montarlo después de un reinicio, puedes seguir los mismos pasos anteriores, asegurándote de apuntar a tu archivo .vhd existente. Además, si desea desmontar un VHD sin tener que reiniciar, debe hacer clic con el botón secundario en el disco VHD en el

Administrador de discos y seleccionar Desprender VHD.

Guardar una unidad existente en VHD

Alternativamente, si lo que realmente te interesa es crear una copia de seguridad de una unidad física de arranque que has creado, de modo que puedas restaurarla en otra (o la misma) unidad usando Rufus más adelante, puedes lograrlo de manera muy sencilla:

Haciendo clic en Mostrar propiedades avanzadas de la unidad en Rufus

Haciendo clic en el icono “Guardar” que aparece junto a la unidad seleccionada

¿Por qué es tan lento el proceso de creación de medios de Windows To Go?

Versión corta: Pregúntale a Microsoft… 😉

Versión larga: El proceso de creación de medios de Windows To Go requiere “aplicar” una imagen WIM a dicho medio, y para ello utilizamos el soporte nativo de la API de WIM de Windows (que, por cierto, es la razón por la que sólo soportamos las ISO de Windows de venta al público cuando creamos una unidad de Windows To Go, ya que, al modo típico de Microsoft, la API nativa de WIM es de alguna manera incompatible con la versión posterior del formato WIM que Microsoft ha estado tratando de utilizar con las ISO de la Herramienta de creación de medios, cuando éstas no están utilizando .esd).

Desafortunadamente, parece que Microsoft no se ha molestado realmente en optimizar su código allí, porque la aplicación de una imagen WIM es de hecho insoportablemente lenta comparada con lo que se puede esperar de una extracción de archivo regular. En otras palabras, el hecho de que la aplicación de una imagen WIM sea tan lenta significa que el formato WIM en su conjunto o el código de extracción de WIM, ha sido muy mal diseñado por Microsoft.

Ahora, ninguna de las alternativas de usar una biblioteca externa (como wimlib) o de crear nuestro propio código son realmente aplicables como soluciones provisionales, ya que añadir una dependencia de wimlib aumentaría enormemente el tamaño de la aplicación, todo por el bien de optimizar una característica que no usa mucha gente (y, si el problema es que el formato WIM está mal diseñado, no ayudará mucho de todos modos), y la creación de nuestro propio código para la aplicación de imágenes WIM es definitivamente algo en lo que preferiríamos evitar gastar tiempo, porque la duplicación de la API de la aplicación WIM ciertamente requeriría mucho de ello, y tenemos características, para las cuales no hay una API nativa que podamos usar, que todavía nos gustaría añadir a Rufus, y por lo tanto, que tienen una prioridad mucho más alta en términos de trabajo de desarrollo en el que planeamos invertir tiempo.

Además, hay que tener en cuenta que aplicar una imagen WIM a una unidad de Windows To Go significa la creación de un montón de archivos pequeños aleatorios (a diferencia de la creación de una unidad de instalación de Windows, donde uno necesita sobre todo copiar un archivo secuencial grande y un número relativamente bajo de archivos pequeños), y, mientras que una unidad flash podría reportar una velocidad de escritura muy buena, esa alta velocidad de escritura podría aplicarse sólo al acceso secuencial y no al acceso a archivos aleatorios, en el que se basa la extracción de WIM. Como resultado, incluso si tiene una unidad que supuestamente puede sostener velocidades de escritura de 100 MB/s, la velocidad de escritura máxima efectiva que la misma unidad puede alcanzar para escribir el tipo de archivos pequeños necesarios durante la creación de una unidad de Windows To Go podría ser mucho más baja…

Lo único que sabemos que puede ayudar a acelerar la creación de una unidad de Windows To Go, es desactivar temporalmente el antivirus. Pero no debe esperar una mejora drástica de la velocidad cuando el problema subyacente es realmente que la implementación de WIM de Microsoft apesta y/o que la velocidad de escritura aleatoria efectiva de su unidad puede ser mucho menor de lo que su fabricante quiere anunciar.