Mensajes

Es que esto va cambiando contínuamente.

Uno que tuve hace unos 3/4 años, me dió varos problemas... tras un corte de luz luego ya no arrancaba, se habían dañado ficheros del S.O. (y alguno que otro de usuario), tras varios tropezones más por la misma causa, decidí darle la patada... (seguía funcionando, pero quedé harto de tener que formatear cada vez que había un corte repentino en el suministro eléctrico (tampoco veo necesario tener que adquirir un SAI, para un equipo doméstico), y se lo regalé a un sobrino... ignoro si sigue usando la misma unidad o si la cambió por otra.

Ahora son más fiables, y es pronto para señalar si tendrán una vida útil igual o superior a los 10 años. Si puedo decirte que enamora, durante las dos primeras semanas, por la notoria mejora en velocidad respecto de un disco duro (digo dos primeras semanas, porque luego te acostumbras y ya es eso lo que esperas). Es más, luego te cuesta si tienes que volver a un disco duro, como sigo yo ahora...

Ve al administrador de dispositivos y en la sección "controladores..." IDE, ATA, SATA (no recuerdo exactamente como te viene), etc... Desinstala las ramas Primary... Channel
Secondary... Channel (por lo menos el canal en la que venga conectado dicha unidad).
Luego reinicia, tras el reinicio, el equipo te dirá que se ha encontrado nuevo hardware e instalará los drivers... posiblemente se haya solucionado el tema. (si tras reiniciar no lo reconociera de modo automático, fuerza a buscar cambios de harware).

Lo que suele ocurrir a veces es que si hay varios fallos seguidos, el S.O. hace caer al dispositivo en el modo de transferencia, de un valor DMA alto a uno bajo (en sistemas antiguos, incluso te bajaba al PIO), creyendo que el dispositivo es más lento, y que por culpa de esperarle, provoca retrasos a otros dispositivos. Al desintalarlo y reinstalarlo, le asigna el valor DMA, adecuado... (si fueron errores transitorios ahí queda todo, si está empezando a dañarse la unidad, esto podría volver a suceder tras no mucho tiempo)...

---------------------------------------------
Ah... y las unidades SSD, no son discos. Un disco, es redondo, con un agujerito en medio y por lo general gira sobre su eje... la unidad SSD, ni es redondo, ni tiene agujerito central, ni gira...  

Yo te sugeriría el corte inglés... claro siempre y cuando el precio de lo que vayas a comprar, no resulte elevado. En informática suele haber cosas caras y 'normales', gangas ya sabes que no vas a encontrar...

https://www.elcorteingles.es/ayuda/como-pagar/

Hacen financiación con su propia entidad...
Aparte como te señalaba un compañero más arriba con tu tarjeta de crédito o débito, podrías hacerlo. Ellos cobran la totalidad y el banco te va cobrando mes a mes, en este caso es el banco quien te cobra los intereses. ante las dudas acude al banco e infórmate de si tu tarjeta actual te lo permite, o si necesitas otra... en tal caso asegúrate también que la cuota de una nueva tarjeta no sea excesiva.

Tengo pendiente mirar lo que hiciste y subiste en GitHub...

Esta mañana antes de marcharme al trabao, hice la prueba y tardaba solo 187segundos, básicamente eleva a 2.666millones de claves por segundo...

Y sí, es sin escribir claves a disco. Ya he mencionado, que es estéril guardar un diccionario a disco, el tiempo necesario para ello es gigantesco comparado con el cálculo, además del espacio gigante que requieren. Cuando se precisa usar un diccionario, y más tarde se interrumpe, basta guardar la secuencia actual (última usada) y luego es relativamente fácil volver a ese punto y continuar. Esto hace inútil tener que requerir un diccionario en disco (un diccionario gigantesco, tampoco pasa nada por tener alguno de unos pocos cientos de Mb.)

Es común ver a alguien 'presumir' de tener un diccionario de nosecuantos GB. Yo cuando oigo decir eso, me apena, por que de lo que está presumiendo (sin saberlo) es de ignorancia.

Los dicionarios en fichero tienen un uso muy restringido, mejor dicho, si quien lo hace lo entiende debería saber que su uso debe restringirse a probar la validez del algoritmo y a casos como: "Diccionarios con las 10.000 claves más usadas en internet.txt", "dicionarios con las claves por defecto de los router 1990-2020.txt", etc... es decir donde no existe una secuencia combinatoria, sino que directamente son conocidas y 'misteriosamente' siguen siendo útiles...

No te preocupes, el código entre VB y C es apenas insignificante, de todos modos con los comentarios que adjunte, podrás entenderlo sin problemas y migrarlo a tu propio código...

(La verdad es que no entiendo bien tu comentario, pero lo aclaro por si acaso):

...Pero entiendo que si es menos "volátil" entonces no sera necesario "activarla" electricamente tantas veces como se tiene que hacer hoy.. por tanto consume menos.

Sí, exactamente... eso es bueno, pero para entender lo que digo, te refiero a la primera línea de mi mensaje:

Por supuesto... y ayudaría también a ocultar más virus y más intrusiones...

Es claro, que si la memoria puede mantener datos incluso sin corriente... entonces no sería distinto de un disco duro, donde en una zona hay algún virus acechante o algún software espaindo... Y sí ya es difícil controlar la seguridad sobre un disco duro, imágina si además puede apoyarse con la memoria.

Tratra de imaginas un simple ladrón... es cuestión de que le cojan o no...
Ahora trata de imaginar que es ladrón además es policía, o que tiene un compinche que es policía... simplemente puede tapar al ladrón, "perseguirlo" pero no alcanzarlo (hacer el paripé de perseguirlo), más aún puede contribuir aportando datos más específicos, incluso puede siendo atrapado, puede abrirle la puerta para que escape... las posibilidades para el ladrón aumentan considerablemente. Es lo mismo si a nivel hardwarte, los soportes de almacenamiento, cuentan con la inestimable ayuda de una memoria que también almacena datos... Exigiría instalar programas, que nada más arrancar el equipo limpie la memoria, para asegurarse que no hayas un virus, pero igualmente ese programa sería hackequeable, luego no tendríamos seguridad.
Una parte buena también tiene... la hibernación (esto es, encendido y apagado) sería instantáneo, no haría falta 'guardarlo' a disco. en contra con esto mismo, un error que cuelga el sistema (el típico Blue Screen Of Death), sería un proiblema de C0J0N3X, porque reinicias y la memoria seguiría ahí corrupta...

En fin, me parece bien que las memorias requieran menos procesos de refresco, por supuesto ahorra energía y gana velocidad (habrá menos interrupciones hardware segurísimo), pero nunca tanto que conlleve a la pervivencia de la memoria tras el fallo sel suministro eléctrico. Esto nos daría más problemas de cabeza.
Imagina incluso una memoria que mantiene sus datos sin refresco (pongamos 10 segundos) durante varios segundos, sería una puerta llena de posibilidad a explotar contra la seguridad... preguntas del tipo: ¿borré los arrays de claves que usé en mi programa, antes de finalizar el programa pero es seguro, que los datos están borrados, o podrían aún ser rescatados, aunque solo sea haciendo un volcado de la memoria y luego con calma proceder a una búsqueda?.
No hay que olvidar que una memoria persistente (por ejemplo usando algún campo magnético), puede conservar estados transitorios que sirven para conocer que dato existía ahí antes del actual... luego el orrado de memoria, no sería 100%efectivo. Y desde luego no tenemos ninguna garantía de que un fabricante haga esto bien, o a propósito deje ventanas abiertas a estas posibilidades.

Resumiendo es un "Nuevo Mundo" de posibilidades y problemas de seguridad que añadir a los actuales. Mientras, el usuario UNIVERSAL (el doméstico, tu, yo cualquiera) no notará grandes beneficios reales y tangibles, pero los problemas potencialmente serían significativos y más al correr del tiempo y los "Badkers" empiecen a enteder el profundo socavón que se guarda ahí y empiecen a idear soluciones para penetrar...

[vendía en internet distintos modelos de un reproductor multimedia]

...quien vendía en internet distintos modelos de un reproductor multimedia denominado Filmspeler, que permite acceder a material audiovisual disponible legal e ilegalmente en internet y visualizarlo en una pantalla...

Cuantas tonterías tenemos que oir. Puedo entenderlo de los 'autores' que son unos agonías que siempre quieren más y más... pero que uno deba oirlo de boca de jueces, ya es para patearlos...

...es que por la misma regla del tres, un vehículo como tal, se vende y el dueño que lo compra puede hacer cosas legales con él, pero también ilegales, ¿entonces... qué?.

¿¿¿¿¿¿Declaramos que los vendedores/fabricantes de coches y vendedores/fabricantes de cuchillos (etc, ab-aeternum), cometen un delito... tal y como se persigue a ese señor que vende televisiones para ver 'contenido' (sea contenido legal o ilegal) ??????????????????

Hola NEBIRE,

quisiera saber que tan eficiente es tu algoritmo para generar diccionarios, para comparar tiempos con el mío y eso.

Me he tomado la molestia de crear un pequeño Snippet en C++11 basado en conversión a base-n donde n es la longitud del charset. Me parece infeciente tener que iterar todo el keyspace en forma de long pero bueno.

Ten en cuenta que le he añadido un hilo para escribir el buffer en el fichero, sino se quedaría esperando hasta escribir todo el contenido. Escribir en el fichero en cada iteracción es un waste de syscalls.

.....

Generar todas las palabras formadas por el alfabeto (26 chars) de longitud 6.

real   0m19.649s
user   0m18.579s
sys   0m2.722s

Donde el mio tarda entre 10s y 12s aproximadamente:

real   0m11.876s
user   0m10.819s
sys   0m2.803s

Si tienes algo de tiempo pásame un code definitivo que guarde las palabras en un fichero, lo testeare en Fedora a ver si difiere mucho del benchmark que te acabo de presentar.

P.D=  Luego esta el maskprocessor que lo hace en 6-7 segs, para mí el más rápido que existe en CPU.

Un saludo!

Bueno, yo separé en efecto la parte de generar las permutaciones del hecho de escribirlo a fichero.
De hecho es ineficiente (e inútil, si el propósito no es otro que probarlo) escribirlo a fichero... siempre sería preferible escribir una API, a la que se pueda llamar y pedir generar (por ejemplo), 1millón de claves a partir de la siguiente (recibida) y que entregue el array por referencia en memoria... Hablamos de que la idea final, sería lógicamente usar las claves en algún programa. Por tanto el coste de escribir a fichero, leer de fichero y espacio ocupado es nulo. Esto sólo debería hacerse con propósitos de prueba... supongo que me tniende sperfectamente.


Tengo varias versiones, ya que me fascina idear soluciones diferentes para un mismo problema. Pero te hablaré de dos versiones básicas... bueno 3...

--------------------------------------
A - En esta la idea básica es la simplicidad del algoritmo.
Y en ella se genera cada clave por completo, simplemente convirtiendo un número decimal (base numérica 10) en la base numérica x, siendo x el tamaño del diccionario (pongamos 26, si el alfabeto fuere por ejemplo A-Z). Es decir esta es la misma que tu has descrito más arriba y que veo en el código...


--------------------------------------
B - En esta otra, la idea básica es buscar velocidad, por supuesto tampoco debe ser muy complejo, ya que sino queda reñido también con la velocidad´.
Así la complejidad subyace sólo en la dificultad de enteder el algoritmo (a pelo, si no se dieran explicaciones).
Entonces para el caso, ni se genera un array de claves. Es la forma más eficiente para usarlo en el propio programa (destinado a probar las claves 'donde fuere').
Esto es, se genera una sola clave y es esa misma la que se va modificando. Ya que en efecto, la diferencia entre una clave y la siguiente solo es (casi siempre) 1 sólo carácter es superfluo generar de nuevo el resto de caracteres de la clave. Por lo tanto generar la nueva clave, cambia casi siempre 1 sólo carácter, lo que dispara la velocidad de cálculo respecto del anterior por 6 (para un tamaño de clave de 6)... algo más al tener en cuenta que tampoco lo almacenamos en un array de claves, aunque por simplicidad en vez de tomarlo como string, es un array de bytes/chars.

-----------------------------------------------------
C - El tercer algoritmo, es más simplificado aún y más veloz que cualquiera de los otros. En realidad usa cualquiera previo, pero éste está diseñado para claves muy largas...
La idea básica es que: 4+4=8: 4+3=7; 5+4=9, o 6+6=12...
Pongamos el caso de una clave de largo 8 caracteres... Luego si generamos pongamos un array para las claves de 4 caracteres (26^4= 456.976) tan sólo algo menos de medio millón, esto se puede generar en apenas una décima de segundo...

Así el paso 1º de este algoritmo es llamar a otro algoritmo, para que genere un array de claves manejable.
El segundo paso, es doble bucle, en ambos se usa el array generado, y la clave generada no se almacena como array (26^8= unos 208mil millones), tal como pasa en el algoritmo B, es para velocidad.
Este doble bucle, simplemente concatena las dos partes actuales.

Código [Seleccionar] Expandir

Inicio bucle Externo:
Por cada ClaveExt en ArrayClaves
    Inicio bucle Interno:
    Por cada claveInt en ArrayClaves
        ClaveActual = claveExt concat claveInt
        // Usar desde aquí la clave que se acaba de generar para lo que se precisa...
        Llamada a funcionX(Claveactual)
    Fin bucle
fin bucle
Como se ve en este tercer algoritmo, generar una clave, se reduce a concatenar dos medias partes. Puede optimizarse mucho, si se usan funciones de copia de memoria, también evitando la creacción y destrucción de strings, o arrays...
Así ClaveActual debería ser una instancia que se crea una sola vez en todo el algoritmo y que se reutiliza una y otra vez. De hecho podemos ver que si ArrayClaves tiene un tamaño de medio millón (500.000), entonces claramente se veque en el bucle interno, siempre estamos concatenando (copiando ClaveExt, a pesar de que sabemos que no va a variar en el próximo medio millón de veces),

Entonces una varicación mejorada del algoritmo sería:

Código [Seleccionar] Expandir

Inicio bucle Externo:
Hacer sitio a claveActual para que sea del tamaño requerido
Por cada ClaveExt en ArrayClaves
    Inicio bucle Interno:
   
    Copiar a Izqierda de ClaveActual, ClaveExt
    Por cada claveInt en ArrayClaves
        Copiar a Derecha de ClaveActual, ClaveInt
        // Usar desde aquí la clave que se acaba de generar para lo que se precisa...
        Llamada a funcionX(Claveactual)
    Fin bucle
fin bucle
Es decir ahora hacemos una concatenación diferida en dos veces...

Otra variación si hacemos una API, que debiera entregar un array de claves de tamaño 8, conllevaría generar el array de claves de solo 4 caracteres, en claves de tamaño 8, dejando así hueco 4 caracteres (a derecha por ejemplo, y que son reutilizados en cada ciclo del bucle Interno), para rellenar en este doble bucle, y donde el bucle interno, sería una adaptación del algoritmo "B" (o sea encajarlo aquí, para hacer la variación de 1 sólo carácter en cada ciclo para generar una clave, en vez de copiar en cada cuiclo los x caracteres de la derecha.

Este algoritmo "C", tien su complejidad, sólo en la forma de adaptación, para hacerlo versátil y que pueda por tanto generar claves de tamaño X, partiendo siempre de la generación de arrays de largo 2,3,4 y 5, desde 2+2, hasta 5+5 y separado si la clave es mayor de 10, para 3+4+4 hasta 5+5+5, etc....
Es decir separando si se quiere hacer doble bucle, triple, bucle, cuádruple bucle, etc...

Código [Seleccionar] Expandir

Si tamañoClaves es menor que 11 luego
    doble bucle
O si tamañoClaves es menor que 15 luego
   Triple Bucle
O si Tamañoclaves es menor que 20 luego
   cuadruple Bucle
en otro caso
   mesanje: no se ha previsto para claves demás de 20 caracteres
fin si

----------------------------------
Ahora mismo, no puedo hacer una prueba de velocidad, ya que tengo algunas operaciones calculando y le llevarán parte de la noche (las pruebas no reflejarían el rendimiento real si el procesador está trabajando al 80%), pero mañana, hago las pruebas que me reclamas y al efecto, limpio el código y cambio nombres de variables para facilitar su entendimiento...

(si creo recordar, de memoria, que poco tiempo atrás, quizás un mes o así, probé a generar con un alfabeto de 26 caracteres (A-Z), para un tamaño de clave de 7 caracteres... lo que proporciona algo más de 8 mil millones y tardó prácticamente unos 5 minutos, es decir aprox. 1.600.000.000 claves por minuto. (en un equipo del 2008, y con una versión hecha en VB6, al caso lo reharé en VB-2010, que es lo que tengo en casa). Dado que el algoritmo anunciado como "A", es la idea básica que tu has hecho, y que el algoritmo "C", está suficientemente descrito, pondré el código del algoritmo "B"...

Saludos...

Por supuesto... y ayudaríqa también a ocultar más virus y más intrusiones...

La RAM, volátil, please... basta que consuma menos.
Me da igual si permanece no volátil durante 1-5 segundos, pero que cuando se le retire el suministro eléctrico, y pasen esos segundos, se pierda su contenido por completo.

Entiendo lo que dice, de "para alguna duda tonta"... peor al ser así, algo irrelevante, la gente se aburrirá, porque así no se aprende, entonces habrñás dos grandes y únicos grupos: "Los pavos" que preguntan chorradas y "el otro" cansado de intentar hacerse entender y ver que fracasa, porque no hay una base mínima a la que los pavos puedan agarrarse y entenderlo bien...

Aparte estoy de acuerdo en todos los problemas susodichos... este foro llevas activo varios años, cualquier de cualquier parte del mundo, puede buscar un tema por la red, y aparecerle este foro, puede consultarse después de años, por cualquiera en cualquier parte del mundo... en whatsapp, cómo dices que se puede buscar algo, quién y cuánto tiempo atrás???.

Todavía si lo que pidieras es llevar el foro al móvil, una versión adaptable a la pantalla tendría un sentido muy razonable, aunque supongo que tiene versión móvil (no he trasteado por todas las ramas del foro, aún).

Pero adelante con tu proyecto, yo te animo, quien sabe, quizás tengas en tu mente una forma muy concreta y clara de llevarlo y dé sus frutos... y si no, pués nada aquí seguirá el foro...

Quién sabe... a lo mejor, el antivirus es efectivo y todo, y ha acertado de pleno, señalando ficheros que efectivamente son virus...