Falsas creencias de los programadores sobre redes y tiempo

En Falsehoods programmers believe about networks un recordatorio de cosas que deberíamos mirar porque probablemente no tenemos claras del todo.

En Falsehoods programmers believe about time otra lista para tener en cuenta sobre el tiempo en los programas que hacen.

Algunas que incluso te encuentras en los primeros cursos de programación,
pero que sigues haciendo mal:

A week always begins and ends in the same month.
A week (or a month) always begins and ends in the same year.

Ya habíamos comentado el de Algunas cosas falsas que los programadores creen sobre los nombres.

¿Cuánto cuesta descubrir tu contraseña?

Es bueno leer de vez en cuando un artículo de estos para conocer el ‘estado del arte’ en estos temas: How many seconds would it take to break your password?. Aunque la velocidad de ataque no avanza tan rápido como creemos, lo cierto es que vale la pena echarle un ojo a los datos:

How long would it take to crack my password: (Includes letters and numbers, no upper- or lower-case and no symbols)

6 characters: 2.25 billion possible combinations

Cracking online using web app hitting a target site with one thousand guesses per second: 3.7 weeks.
Cracking offline using high-powered servers or desktops (one hundred billion guesses/second): 0.0224 seconds
Cracking offline, using massively parallel multiprocessing clusters or grid (one hundred trillion guesses per second: 0.0000224 seconds

Yo suelo usar (aunque ya tiene algún tiempo) una tabla construida a partir de Datos de seguridad en contraseñas.

el objetivo tampoco es los datos exactos de tiempo (que van cambiando) sino que quede claro que:

¡El tamaño importa! (y la complejidad).

¿Seguro que es el mejor algoritmo?

Cambiamos un poco de tema. En Think you’ve mastered the art of server performance? Think again. el análisis del coste de una solución cuando empiezan a entrar diversos factores que afectan a cómo la teoría interpreta los resultados.

Por ejemplo, algunas suposiciones puede ser importante:

A quick browse of the mental catalog flipped up the binary-heap card, which not only sports an O(log2(n)) transaction performance, but also has a meta-data overhead of only a pointer to each object—which is important if you have 10 million+ objects.

La memoria virtual:

It took quite some time before virtual memory took hold, but today all general-purpose, most embedded, and many specialist operating systems use VM to present a standardized virtual machine model (i.e., POSIX) to the processes they herd.

Y como seguimos ignorándola a la hora de medir teóricamente algunas cosas:

The fact is, however, 46 years later most CS-educated professionals still ignore VM as a matter of routine. This is an embarrassment for CS as a discipline and profession, not to mention wasting enormous amounts of hardware and electricity.

Por eso,

What good is an O(log2(n)) algorithm if those operations cause page faults and slow disk operations? For most relevant datasets an O(n) or even an O(n^2) algorithm, which avoids page faults, will run circles around it.

Por eso, nosotros siempre recomendamos medir teóricamente para tener una idea de por donde van los tiros. Pero luego probar con nuestros sistemas reales y con los datos de verdad, para estar seguros de que los resultados teóricos se mantienen.
Y, por supuesto, esto nos da pistas de por qué es importante saber de hardware, del sistema y tratar de estar al día en muchos de estos temas.

Divertido, ¿no?

¿Por qué GNU grep es rápido?

La respuesta en why GNU grep is fast y lo explica haciendo referencia a los aspectos técnicos pero sin meterse mucho en los detalles.

Esencialmente:
Se utiliza el algoritmo de Boyer-Moore, que tiene como ventaja que evita mirar los bytes uno a uno, porque es capaz de evitar algunos basándose en información sobre lo que se busca (letra final, tamaño y aprovechándolo para dar saltos más grandes).
Pocas operaciones sobre cada byte de los que realmente se miran.

Además, el bucle interno está ‘desenrollado‘, lo que le evita algunas operaciones extra (las de control del propio bucle, claro). También evita pensar en líneas (salvo cuando ‘cree’ que ha podido encontrar lo que buscaba y trata de gestionar mejor la memoria para que la lectura sea más eficiente.
¿Alguien se anima a echarle un ojo al código?

¿Cada cuánto cambiar la clave?

Una aportación al tema de Bruce Schneier, Changing Passwords:

So in general: you don’t need to regularly change the password to your computer or online financial accounts (including the accounts at retail sites); definitely not for low-security accounts. You should change your corporate login password occasionally, and you need to take a good hard look at your friends, relatives, and paparazzi before deciding how often to change your Facebook password. But if you break up with someone you’ve shared a computer with, change them all.

Un fallo de 17 años

Esta vez se trata de un fallo en Windows, Windows plagued by 17-year-old privilege escalation bug. Concretamente afecta a la ‘Virtual DOS Machine’ introducida en 1993 con Windows NT. En Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack se pueden ver más detalles del fallo.

Es una cosa medio técnica y poco ‘glamourosa’ (creo), pero ¿por qué lo traigo aquí?
Me gusta recopilar este tipo de cosas, y ya habíamos hablado de fallos que permanecen mucho tiempo y que aparecen años después (en esta ocasión casi con la ‘mayoría de edad’) en El mito de los miles de ojos, hablando del software libre y este que traemos ahora es de software privativo, pero de difusión muy amplia.