Los virus van mas rápido que la informática

(PD: Esto hubiera funcionado igualmente si la chica hubiera usado jabber. O un .desktop en linux)

victima  07:06:47 pm
  Mira las fotos >>> http://hometown.aol.com.au/miralafoto/foto.exe

diegocg@teleline.es  07:08:09 pm
  uh-oh :/
  señorita, tiene usted un virus

victima  07:08:26 pm
  yo??
  por?

diegocg@teleline.es  07:08:34 pm
  ¿me has puesto tu esto?
  victima  07:06:47 pm
    Mira las fotos >>> http://hometown.aol.com.au/miralafoto/foto.exe

victima  07:08:58 pm
  esq eso m lo a mandado a mi otro
  no m jodas q es un virus?

Superfetch

(voy a poner esto aquí, que luego se me olvida y así lo tengo googleable :P)
Resulta que se rumorea de una nueva cosa que vendrá con vista, llamada superfetch. Parece un derivado del prefetch. El prefetch consiste en: Monitorizar la aplicacion, guardar la información, y la próxima vez que se vaya a cargar la aplicación cargar de manera eficiente la información que ese programa va a necesitar

Ahora bien: El superfetch es otra cosa. La idea consiste en que "donas" parte de tus llaves USB como espacio para guardar caches. En vez de monitorizar la aplicación y luego intentar cargarla de manera óptima, metes los datos que va a necesitar en la llave USB, una duplicación literal de la información, para inyectarla (supongo) en el cache de páginas. De esa manera se acelera la carga de aplicaciones, porque las llaves USB son más rapidas que un disco duro moviendo el brazo para todos lados

Y la cosa es que me parece absurdo. Puestos a crear una "duplicación" de la información del disco: ¿por qué guardar dicha duplicación en un formato que permita su lectura secuencial? Quiero decir: El disco cuando tiene que hacer búsquedas es muy lento, pero cuando se trata de leer información sin mover el brazo es MUCHO más rápido. De manera que si en vez de crear ese "cache" en las llaves USB lo guardas en el disco, te aumentará la carga de aplicaciones igualmente. Con la ventaja añadida de que no puedes hacerlo solo cuanto tienes llaves USB, sino todo el tiempo y para muchísimas más aplicaciones

Frases interesantes

De aquí (se me han tirado al cuello algunos BSDeros por contarles que Linux en cuanto a número de plataformas portadas puede ir con la cabeza muy alta)

"Y sinceramente, me extraña poderosamente que un amigo que quiere olvidarse de los virus y cuelgues de su XP te pida consejo y tú le recomiendes ****BSD. ¿No puedes al menos reconocer que es MEJOR que le recomiendes Linux? Eso es ser fanático"

Charla de Hurd

En Umeet hubo hace unos días una charla sobre Hurd. Siempre es interesante comentar los comentarios HURDianos. La primera cosa de la que uno se da cuenta es que para Hurd dos de los dos ejemplos más importantes que pretenden conseguir son la seguridad y la calidad de servicio, que por alguna razón el conferenciante cree ajenos a los sistemas operativos no microkernels. A nadie parece importarle en absoluto que el problema número uno de los sistemas operativos de hoy sea su falta de integración con la red.

La primera cosa que uno escucha es como se meten directamente con el modelo de seguridad de Unix, algo con lo que estoy muy de acuerdo porque está obsoleto. Pero evidentemente, esta gente no ha escuchado que existe SELinux - implementado por la NSA e inspirado por algún que otro sistema operativo experimental que curiosamente corria sobre Mach - y que Linux de hecho soporta varios modelos de seguridad. Varios. Lo digo por si hay alguien que de verdad se traga aquella bazofia de que solo los microkernels pueden diseñar software de forma modular, flexible y extensible, como si el diseñar software bien fuera algo atado intrínsecamente a usar un sistema de paso de mensajes por IPC en vez de llamadas a funciones. Porque por lo que tengo leido, los fans de los microkernels se lo tragan de verdad.

Otra cosa donde dice que los sistemas operativos "fallan" es en la calidad del servicio, como hacer un find / mientras ves un DVD. De nuevo, este tipo no ha oido hablar de que linux tiene un subsistema de IO totalmente modular y que uno de los schedulers IO es CFQ, que soporta el concepto de "prioridades IO" y que permite poner a ese find / una baja prioridad IO para que no afecte el DVD.

Lo dije aquí una vez y lo repetiré: El diseño de software no está vinculada a ser un microkernel o no. El diseño de software de hecho se da en cualquier software no solo en un kernel. Y es por esto por lo que no hay nada que impida que un kernel "monolítico" sea modular y extensible. NADA. De hecho, que yo sepa el subsistema de IO de Linux es uno de los más flexibles que existen, tanto que he sido incapaz de encontrar en google rastros de sistemas operativos que permitan, como linux, tener varios schedulers de IO, poder cambiarlos al vuelo y poder insertar nuevos schedulers con diferentes algoritmos o quitar los que no quieres tener.

Asi que ¿qué he aprendido de la charla de Hurd? Que me va a salvar de cuelgues - a pesar de que yo con linux no tengo cuelgues -, que tiene un modelo diferente de seguridad sin implementar del todo y que linux ya tiene, y que en el futuro van a modificar su subsistema IO para llegar a una flexibilidad y modularidad que linux tiene hace más de 1 año. Me ha resultado extremadamente interesante esta charla, si. Mañana instalaré Hurd. Fijo

Razones para usar kernels precompilados (toma 2)

Hay una especie de "regla no escrita" en el mundo linuxero que dice que toda persona "debe" compilar su propio kernel, como parte de su proceso de aprendizaje o de incremento de su "estatus geek". Nada más lejos de la realidad: El kernel, al igual que el resto del software del sistema, no deberia necesitar compilarse - como cualquier software diseñado decentemente. Lo que mucha gente no sabe es que Linux 2.6 es lo suficientemente avanzado como para que un kernel precompilado funcione perfectamente sin retoques en la mayoría de sistemas

• Razón 1: Hay un mito sobre el kernel: La gente piensa que optimizando el kernel, el sistema irá más rápido, y que si no lo haces irá lentísimo y estarás desaprovechando tu equipo.
  
  Vamos a ignorarlo y hacer un análisis serio. Pregunta: ¿Cuanto tiempo de CPU gasta un sistema normal ejecutando codigo en espacio de usuario y cuanto gasta ejecutando código del kernel?. sar (maravilloso programa que no debería faltar en vuestros sistemas) puede decirlo:
  

  20:05:01          CPU     %user     %nice   %system   %iowait     %idle
  20:05:01          all      6,23      0,00      0,50      0,25     93,03
  

  
  Como se puede ver en este caso, de todo el tiempo de CPU transcurrido en mi sistema en un uso típico de escritorio (email, firefox, escribir artículos malos) solo un 0.50% del tiempo de CPU ha sido utilizado por el kernel, y un 6.23% por programas de espacio de usuario (un servidor dará diferentes números, de hecho un servidor web dará porcentajes diferentes a un pc haciendo de router). Es decir, 12.46 veces más. De todos los ciclos de CPU durante el que se ejecuta "software real" (todo lo que no es tiempo "idle") el 92.57% se ejecutan en espacio de usuario, y un 7.42% en el kernel.
  
  Lo que quiere decir esto es que en un uso normal el sistema se pasa la mayor parte del tiempo ejecutando software en espacio de usuario, y que por lo tanto optimizar el kernel no mejorar el rendimiento del sistema de manera notable, por la simple razón de que la mayor parte del tiempo no es su código el que se está ejecutando. En las distros precompiladas tiene especialmente poco sentido: ¿Para qué optimizar para el procesador de turno el 7.42% del tiempo de ejecución si el software que se ejecuta el 92.57 del tiempo está "optimizado" para i586 o i386?.
  
  Esto tampoco quiere decir que la optimización no influya en absoluto: Hay ciertas funciones (como las funciones que mueven porciones de memoria de un sitio a otro) que se utilizan mucho y algunas tienen incluso optimizaciones específicas en ensamblador. Lo que quiero decir es que esperar que el optimizar el kernel vaya a acelerar notablemente un sistema típico es lo mismo que esperar que un grano de arena sea distinguible en un desierto.



• Razón 2: Las diferencias entre procesadores puede que no justifican la optimización. Eso tampoco quiere decir que no existan esas diferencias o que no vayan a influir: Simplemente, las diferencias no son tan grandes como para justificar la optimización. Las distribuciones suelen tener un kernel i586 por defecto (excepto ubuntu y debian) y muchas kernels precompilados adicionales disponibles (para k7, para athlon64, para p4) en los repositorios. En serio, no necesitas recompilar el kernel solo porque en el kernel no añadieron una opción al gcc que tu "sabes" que en "teoria" optimiza mucho el ejecutable para tu máquina. Como ejemplo extremo está Ubuntú: Su kernel por defecto está optimizado con instrucciones de i386 (pero optimizadas para un pentium 4, esto es otro tema), y apuesto a que mucha gente ni siquiera se ha dado cuenta. Además hay que tener en cuenta una pecularidad de la plataforma x86: Todos sus procesadores se parecen "enormemente" entre si. De hecho, es la base de su éxito: Si x86 está donde está es en gran parte por no cambiar demasiado y preservar la compatibilidad lo máximo posible. En general, cuando las empresas dedicadas a CPUs preparan una nueva versión de CPU intentan copiar al máximo y dentro de las posibilidades de la nueva arquitectura el comportamiento de los procesadores anteriores, por la simple razón de que los compiladores tardan años en optimizarse para una arquitectura determinada. Eso puede suponer que al salir el producto a la calle el rendimiento sea pobre y que el producto fracase comercialmente. ¿A alguien le suena Itanium?
  
  Una de las principales diferencias entre los x86 (además de las diferencias fundamentales como netburst vs opteron etc) son las extensiones "multimedia": MMX, SSE, 3dnow. Estas son especialmente irrelevantes para el kernel: Existe una regla en el kernel que prohibe utilizar código en punto flotante en el kernel excepto en unos pocos lugares controlados (usarlo demasiado obligaría a guardar los contenidos del coprocesador matemático entre cambios de contexto y eso enlentecería mucho el kernel). Se utilizan en algunos puntos, pero se evitan como si tuvieran la peste
  
  Lo que quiero decir aquí es que esto es como los benchmarks de Intel vs AMD: "En x benchmark AMD gana a intel un 5%". Si, el AMD es más rápido, pero esa "ventaja" supone que en vez de tardar un minuto el amd lo hace en 59 segundos, que es prácticamente lo mismo. Es muy probable que no notes las optimizaciones que estes haciendo al compilar a mano el kernel. Son demasiado pequeñas. Las principales diferencias vienen casi siempre de mano los algoritmos: No hay optimización de procesador en el mundo que vaya a hacer que el kernel descarte correctamente tal o cual dato en el cache de disco o el orden correcto en el elevator del kernel, por ejemplo, y te aseguro que esa decisión va a influir muchísimo más en el rendimiento de tu máquina que cualquier optimización a nivel de procesador



• Razón 3: Seguridad: Si descargas y compilas tu propio kernel, el día que haya un fallo de seguridad en el kernel tendrás que: 1) Enterarte. Algo que no es fácil, porque los fallos de seguridad del kernel casi nunca se reportan en barrapunto o slashdot o osnews (y si piensas que si, significa que no te has enterado de muchos fallos de seguridad o incluso de que alguien ha hackeado tu servidor gracias a uno de esos bugs y tiene instalado un rootkit en él ahora mismo, y no tengo por qué estar siendo paranoico) 2) reconfigurar 3) recompilar
  
  Sin embargo, si instalas un kernel precompilado, lo instalarás a partir de los paquetes de tu distro, y los sistemas de actualización de tu distro te lo actualizarán automáticamente en cuanto haya nueva actualización de seguridad. Es una opción bastante más inteligente...



• Razón 4: Tener muchas cosas (opciones) compiladas en el kernel no daña necesariamente el rendimiento: Alguna gente se cree que tener todos los sistemas de archivos en el kernel, o la emulación de coprocesador matemático va a hacer las cosas mas lentas. ¿Por qué? No se trata mas que de un gran IF: Si algo no se usa, no tiene porque afectar al resto. El código de un dispositivo que no se tiene jamás se ejecutará. Y por supuesto la mayoría de kernels precompilados no hacen esas cosas - se modularizan las cosas exageradamente, hasta el punto que algunas distros nisiquiera compilan el sistema de archivos del sistema de archivos root / en el kernel, compilan todos como módulo y cargan el necesario en el initrd



• Razón 5: Tener muchos módulos es útil: La gente suele compilar su kernel porque quiere "compilar solo el soporta para su hardware y quitar el resto". Esto está relacionado con el punto anterior. La pregunta es: ¿Por qué? Los módulos no utilizan nada más que espacio en el disco al menos que no se carguen. Probablemente tengas un /usr/X11R6/lib/modules/drivers/vmware_drv.o en tu sistema. ¿Recompilas las X solo para desactivar ese driver? ¿Recompilas para desactivar las librerias de accesibilidad de gnome solo porque no las necesitas? Tener 100 o los módulos que sean ahí no hace daño. Tampoco es ninguna guarrada: Es lo correcto. El objetivo del kernel es que tu hardware funcione, y el soportar más hardware del que tienes significa que podrás cambiar de hardware sin recompilar el kernel: Y esto es importante para todos, porque con USB y firewire es imposible determinar en tiempo de compilación que dispositivos vas a acabar conectando a tu equipo. La flexibilidad es una característica del software, y es buena.
  
  Una vez sufrí un problema relacionado con esto: No tengo un lápiz USB, asi que no tenía compilado el soporte. Pero resulta que un amigo vino con un disco duro externo USB, y como no tenia ganas de hacerle soportar la espera de compilar un kernel, tuve que iniciar en Windows. Windows paraba la transferencia a la mitad y el driver dejaba de funcionar asi que finalmente tuve que hacer esperar a mi amigo. Moraleja: Un sistema moderno tiene USB y firewire y por lo tanto no tiene una configuración de hardware estática
  
  Udev es quien se encarga de hacer gran parte del trabajo de configurar el hardware del sistema y cargar los modulos de tu hardware y no cargar los que no son. Si yo por ejemplo enchufo mi webcam Creative Go Plus, el kernel notifica a udev de que se ha insertado un dispositivo en el bus usb, udev mira que es mirando identificando el hardware y carga los dos ó 3 módulos de soporte básico de USB, el módulo de la camara, el módulo del chip de la camara, y el módulo de V4l. Automaticamente. Pero si no la enchufo, no las carga, y puedo hacer que udev descargue los módulos cuando desenchufo la cámara - no hay "bloatware" en ningún lado. Las máquinas se inventaron para hacer cosas por nosotros. Utilizalas para ello y utiliza un kernel precompilado y udev. Muchisima gente de la que compila su kernel a mano no activa el soporte de hotplug (necesario para udev), porque piensa "que no lo necesita". Lo cual nos lleva al siguiente punto



• Razón 6: Configurar el kernel no es fácil y los mantenedores del paquete precompilado saben que necesitas mucho mejor que tú, aunque no lo creas: El número de opciones disponibles en la fase de configuración del kernel se multiplica en cada versión, y a día de hoy es prácticamente imposible saber configurar correctamente todas las opciones. Mi config tiene 1034 opciones diferentes entre las activadas y desactivadas. ¿Sabes configurar correctamente esas 1034 opciones? Puedes pensar que sabes, pero siendo realistas no hay nadie en el mundo que sepa configurar por si mismo un kernel por completo. Yo llevo años compilando decenas y decenas de kernels por afición al desarrollo del kernel, y aun hay muchas opciones que no se que hacen, ni si debería activarlas o no. Ni tan siquiera los hackers del kernel lo saben, ni Linus Torvalds, te lo aseguro (bueno, quizás Alan Cox...) Los que mantienen una arquitectura no se enteran de que cosas están haciendo los del soporte USB, y viceversa. Por si fuera poco, muchas opciones no están documentadas (o están mal documentadas, que es peor), algunas son peligrosas y otras no puedes saber si activarlas o desactivarlas porque simplemente te da lo mismo (como pasa con cualquier proyecto software que tenga este tamaño: nadie puede conocer 200 MB de código C, además en linux se tiene la "manía" de hacer todo extremadamente configurable hasta el punto que dudo mucho que exista un kernel más configurable) Y la configuración por defecto que trae el kernel de kernel.org está muy lejos de tener los valores por defecto ideales. Moraleja: Deja que los mantenedores de tu distribución se ocupen de la compleja tarea de configurar el kernel. Ellos tienen los recursos (varias personas, sistemas de seguimiento de bugs por si se equivocan en algo, etc) para hacerlo, tú no.

¿Y esto para que lo escribo? Para intentar evitar que la gente se pase la vida compilando kernels por "tradición". Eso no quiere decir que esté prohibido compilarles: Compilar kernels es una actividad divertida y entretenida para un geek, siempre que tenga una razón para ello (por ejemplo, que le da la gana). Lo absurdo es hacer lo que hace la gente: Compilar por que si, sin tan siquiera tener ganas, como si fuera una "obligación" a su estatus de "geek".

Ingo Molnar es Dios

Si a alguien le interesa el tema de "bloqueos" y de las intenciones que tienen algunos de sustituir a los semáforos por mutexes (con las ventajas de tener menos instrucciones, menos código) en el kernel linux, que lea aquí. Si alguien me busca, estaré buscando parecidos y diferencias entre semáforos y mutexes en google :/

Firefox 1.0.x NO se está actualizando a 1.5.0

Lo digo por si alguien no se había dado cuenta. Resulta que el equipo de actualizaciones NO ha hecho nada para que las instalaciones de Firefox 1.0.x se actualizen a 1.5.0.

Lo reporté el otro día (#319440), pensando que algo tan obvio ya se sabría de antemano, o que alguien ya lo habría reportado, y que me enteraría de que narices estába pasando cuando alguien me lo marcara como duplicado o lo cerrara como inválido. Cual fue mi sorpresa al comprobar que aceptaban el bug y reconocían que aun no han hecho nada, que 1.5.0 está ahí pero que no lo han metido en el sistema de actualizaciones de 1.0.x aun. La mayoría de usuarios de los 100 millones de instalaciones aun usa 1.0.x.

Por eso digo: Si habeis recomendado a alguien firefox antes de que saliera 1.5.0, y quereis que se actualizen antes de que arreglen este pequeño fallo (no tardarán mucho), avisadles para que se lo bajen manualmente

El tamaño no importa

La revista francesa "Jalouse" ("celosa" en castellano) destinada al público femenino ha sido noticia ayer por incluir como parte del último número del año un consolador para sus lectoras. "Good vibrations 2006" era el título de esta edición. Se han publicado 50.000 ejemplares con este artefacto y oh, sorpresa sorpresa, se han acabado en un santiamén. En otra ocasión pusieron la foto de un tipo en pelotas con las partes tapadas con un círculo que había que rascar en plan "rasca para ver lo que hay debajo"

Y esto ha generado bastante polémica, pero a la mayoría de las personas parece parecerles bien la idea: hay que quitar tabues al sexo, vivimos en un pais moderno (sobre todo nuestros vecinos comparados con nosotros, que nos llevan siglos de ventaja en mas de una cosa, incluida la integración de inmigrantes y eso a pesar de las recientes quemas de coches, y si no esperen un par de décadas a ver la que se monta aquí) y que demonios, por qué no alegrar la cara a las mujeres de este pais. A base de cilindros a pilas que siempre son tamaño XXL (el tamaño no importa, y todo eso)


Y ahora imagínense ustedes por un momento que es una revista masculina la que tiene la iniciativa. Que la FHM o quien fuera regalara una vagina en lata, o una muñeca hinchable, o algo asi. Y en este pais. Las asociaciones feministas presentando demandas al juzgado contra FHM por tratar al sexo femenino como objeto. La Iglesia poniendo el grito en el cielo por que utilizar los órganos sexuales en algo que no sea un matrimonio y para algo que no sea la fecundación hace llorar al niñito Jesús. Las columnistas de las revistas femeninas análogas a la Jalouse haciendo chistes y análisis del evento: Si es que estos hombres. Que simples son, que fácil se dejan llevar por arrebatos primitivos, mira que nosotras no estamos tan salidas. Solo piensan en sexo. Los muy cerdos.

PD: Espero que las féminas que lean esto comprendan que lo escribo con mala leche y que lo "sexualmente correcto" hoy me importa una mierda.

caca culo pedo pis

He puesto esas palabras, a ver si hay suerte y aumentan las visitas. Porque desde que tengo puesto lo de google analytics me entero de las busquedas que hace la gente para llegar a mi página. Aquí tienen ustedes una lista:

(PD: No se quien será el cerdo salido que busca tantas fotos de Marta Nebot la reportera seria de la Noche Hache en Cuatro. Pero si lee esto y las ha encontrado, que me las mande por correo. PPD: Si, uno de los propósitos de este post es aumentar las visitas :P)

Keyword/Source[Medium]
hora hache
marta nebot
rouco varela
en informatica que es un parche y para que me sirven
la hora hache
inglesas putas
marta nebot fotos
donde estudian los hijos de pepiño blanco
diego calleja
emacs paquete deb
nuevo sistema de archivos zfs
burnlounge scam
fotos anti estatuto
windows server 2033+kernel
activar ie7
marta nebot, fotos
pancarta manifestacion personalizable
transparencias mejoras rendimiento cpu
hora hache medios
algoritmo+ascensor
redhat deadline io
"marta nebot"
fotos d politicos d risa
instalacion dual windows linux
"la guerra de los medios" cuatro
instalar xorg en debian
una pequeña definicion de los sistemas operativos
zfs en solaris
cosas d febrero

"hacking ético"

Asi se titulaba el título de un libro que acabo de ver esta tarde en una biblioteca. Con un título así uno se pregunta si es que los hackers normales necesitan un cursillo para hacerse éticos. Tendré que mandar un email a los hackers del kernel preguntándoles si el hacking suyo es ético, o no. Y recomendándoles el libro, incluyendo el ISBN en el email, para que se lo compren, y aprendan. No vaya a ser que estén hackeando cosas sin llevar a la ética por bandera.

Y es que aunque exista aquel dicho de "no juzgues un libro por las tapas", a veces un libro se puede juzgar fácilmente por las tapas. Al igual que pasa a veces con las personas (o como decía fromoze el otro día, "la gente interesante se reconoce a leguas")

Esto del "Hacking ético" da mucho más que pensar. No se si he comentado alguna vez que mi inicio en el mundo de la informático se vió fuertemente incluenciado por el mundillo este del aparente "hacking ético" y por una especie de "proyecto" llamado hackindex (es impresionante lo flexible que pueden a llegar palabras como "proyecto"). Con el paso del tiempo descubrí no solo que el hacking "ético" no tenía demasiado interés para mi, sino que era absurdo incluso para aquellos que continuaban ahí. La existencia de grupos de news tipo "comp.blah.misc.hackers" es ridícula, pensé. Las personas son programadores expertos - hackers - de redes, kernels o cortafuegos, y por lo tanto su actividad debe estar localizada en grupos de redes, kernels o cortafuegos. ¿Que demonios es una lista de "hacking"? ¿Un "todo" donde todo cabe, sean redes o kernels? ¿Una nueva definición de "computer science"? Me parece tan estúpido, que dejé eso del hacking aparentemente ético y me fui a listas de correo y foros donde hackers - hackers de verdad - discutian por ejemplo sobre el kernel, como la lista del kernel de linux, o de lo que tocara. Sitios donde lo que se discutía era sistemas operativos, redes, o lo que fuera, no el "hacking ético".

Es curioso lo del hacking "ético" este por cierto: En listas como la del grupo hackindex te daban consejos, métodos para penetrar en ordenadores que nunca eran anonimos, código de exploits para vulnerabilidades corregidas que por supuesto todo el mundo quería solo para estudiar no para usarlos, rootkits que nadie instalaba en máquinas de otros, y despues de aquello soltaban aquello de: es tu responsabilidad, si haces algo malo no me cargues con los muertos. Te damos los planos para construir la pistola, te conseguimos las balas, te la cargamos, te la ponemos en la mano, apuntamos por ti hacia la cabeza de un fulano, te ponemos el dedo en el gatillo, pero el que lo aprieta eres tú. Yo y mi conciencia estamos 100% libres de culpa, y seguiremos en nuestra lista de correo fabricando más y mejores pistolas por el bien de la humanidad y la ciencia. Pero cuantos hipócritas hay en ese mundo.