25 de diciembre de 2005

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"

21 de diciembre de 2005

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

20 de diciembre de 2005

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

19 de diciembre de 2005

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

8 de diciembre de 2005

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

1 de diciembre de 2005

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

29 de noviembre de 2005

amo kdevelop



No se como coño es visual studio, pero esto es la repanocha (el shell integrado es muy comodo para abrir sesiones de clientes de irc de texto). Y eso que no he sacado la ventanita de "fragmentos de código". La sensación de claustrofobia se debe a que estoy a 800x600 (si, lo se)

25 de noviembre de 2005

Las patentes de software son buenas para la economía

Y lo digo totalmente en serio. Es más, un mundo con patentes de software permite a las empresas tener más beneficios que un mundo sin ellas. Del mismo modo, el software propietario permite mayores beneficios que el software libre. Lo mismo para el DRM, y para una imaginaria ley anti-derecho-de-copia-privada. Y antes de que alguien me ponga verde, he de hacer notar que he escrito mayores beneficios, no que en un mundo con software libre y ausencia de patentes no se pueda ganar dinero

La mejor prueba es Microsoft. Una empresa que tiene a sus usuarios literalmente cojidos por los huevos. Puede hacer lo que le da la gana, millones de personas comprarán lo que ellos vendan. ¿Puede Red Hat hacer dinero en este mundo? Si, pero nunca podrá hacer tanto dinero como Microsoft. Imagina que el código de Windows fuera libre.

Lo del título de las patentes lo decía porque antes de que se votara la resolución aquella que hizo que el tema éste dejara de estar tan de actualidad, hubo un tipo del comite o lo que fuese aquello - no recuerdo el nombre - que iba con buenas intenciones y nos decía a los anti-patentes algo del tipo "Os escuchamos, pero (casi) todas las grandes empresas del sector están a favor de las patentes", como diciendonos: Joder, ya se que teneis razón, pero estas empresas son las que mueven el dinero en vuestro sector y si ellas están a favor no vamos a llevarlas la contraria, que son ellos quienes crean riqueza y a quienes hay que favorecer. Lo que no dijo el tipo es que probablemente a las empresas nunca les importa ese tipo de leyes, como tampoco les importaría una ley que obligara a trabajar 14 horas diarias.

Lo que quiero decir es que lo que decía el tipo del comité ese es obvio. Las patentes permiten a las empresas ganar más dinero. Lo mismo para el DRM, etc. Lo verdaderamente escalofriante no es que las empresas quieran leyes así, lo escalofriante es que haya politicos que nos digan a los ciudadanos a la puta cara: "Lo siento macho, pero las empresas mandan. Ellas crean empleos y si ellas quieren algo, hemos de concedérselo por vuestro bien" y que se queden tan panchos. Y que la gente se quede igual de pancha.

Yo no estoy en contra de las patentes de software porque crean que dan mas dinero. No lo dan: Si pudiera patentas el click, por ejemplo, me haría millonario y no hay argumento anti-patente que pueda rebatir eso. Si estoy en contra de las patentes es porque estoy a favor de derechos, no de beneficios. Esa es la misma razón por la que estoy a favor del software libre, en contra del DRM, y demás. En el fondo sean patentes, DRM, SGAE y la copia privada, canon y demás, se trata siempre del mismo problema: No hay una definición clara entre los derechos de los usuarios y los de las empresas. Y en vez de atajarlo directamente, acostumbrados como tenemos acostumbrados a nuestros políticos a hacer el imbecil, lo damos vueltas y vueltas alrededor de él en forma de copia privada, DRM, patentes. ¿Por qué a una empresa de hardware no se la obliga a liberar las especificaciones cuando quiebra o cuando termina el periodo de soporte, o porque no se la obliga a soportar un mínimo de sistemas operativos?

Pasa en otros temas. Por ejemplo, los políticos suelen hablar de "flexibilidad laboral" a cosas como los contratos de los que a los 6 meses a la puta calle. Nos ha jodido. Flexibilidad laboral, hay que joderse. Y gracias a la flexibilidad laboral, España va bien y el PIB está por las nubes. Y si ponemos una ley que obligue a los trabajadores a trabajar sin cobrar sueldo, mas que subirá; y si hacemos que todas las empresas puedan despedir a cualquier trabajador cuando le da la gana, más fléxibilidad laboral y mas felicidad de la directiva, nos ha jodido. Tal vez sea que un PIB alto no indica que un pais va bien o al menos la gente no debería creerlo así, y que leyes que permiten a las multinacionales informáticas aplastar a las pequeñas empresas no son siempre buenas. Personalmente creo que es uno de los problemas más importantes de nuestras sociedades de cara al siglo XXI, y creo que es un gran problema porque a la gente le importan una mierda sus derechos y que las empresas se rian de ellos siempre y cuando el PIB sea alto y el bolsillo este lleno

23 de noviembre de 2005

La Xbox 360 casca

No sorprende viniendo de Microsoft. Habrá que esperar al Servispak, etc. Asi son los comentario graciosos que se oyen con motivo de la noticia de que la Xbox casca

Fotos, videos...aparentemente es sobrecalentamiento (3 powerpc consumiendo lo suyo, el chip grafico, todo en una cajita pequeña...). Pero este es un ejemplo típico de como las empresas nos toman el puto pelo y trabajan bajo presión para sacarnos los cuartos. Especialmente es un buen ejemplo de como Microsoft trabaja: Ve un mercado donde puede colarse, y se lanza como un tiburón a por él. De la estabilidad ya nos preocuparemos urgentemente cuando tengamos la mayoría de mercado y los cuartos asegurados reemplazando las consolas usadas - cuatro duros menos de ganancias - y aparentando ser chicos buenos. No vamos a retrasar el lanzamiento de la xbox porque un tipo de los de control de calidad dicen que unas pocas consolas se calientan

Ojala no vendais ni una puta consola más, por cabrones. Ni los de Sony, que son más de lo mismo. Malditas multinacionales de mierda

22 de noviembre de 2005

muerte a los drivers propietarios

Greg Kroah-Hartman, que es mi heroe, ha intentado provocar a la gente con un bonito parche que hace que todos los simbolos exportados del subsistema PCI (del que es mantenedor, por cierto) sean GPL. Es decir, que ya no se podrian escribir más drivers propietarios (nunca se ha podido en realidad). Luego ha mandado otro mensaje explicando que no iba en serio pero que las empresas deberian pensarselo porque la cosa para ellos va a peor (algunos subsistemas como sysfs solo permiten drivers compatibles con la GPL...)

Han respondido unos cuantos. Sin flamewars, porque todo el mundo esta con él - los drivers propietarios deberían desaparecer. Luego, el mantenedor de PPC ha explicado que incluso ATI, que solia hacer drivers 2D libres, ha creado un nuevo chip no compatible con los anteriores y que en el terreno de las tarjetas gráficas la cosa va a peor

El mensaje mas interesante del hilo es probablemente la respuesta a éste último, de Alan Cox:

Its easy to see why

The graphics market between Nvidia and ATI is extreme rivalry
There have been some ugly patent lawsuits
Good software tricks can make the weaker hardware win
Its very hard to write


So there are real secrets left in the market. Designing a SCSI
controller isn't exactly a McJob but its commodity.


Nvidia are at least trying to do what they can within what for them is
not a very easy set of market conditions for open sourcing. ATI were
doing very nice things until they won the Xbox 360 contract. An
observation that perhaps would not go amiss reaching the US legal
watchdogs.

16 de noviembre de 2005

ZFS de Solaris publicado, y I/O con prioridad

Tal y como se puede leer en osnews, el nuevo sistema de archivos de Sun ha sido liberado. Y digo liberado porque se ha publicado en opensolaris y está disponible con su código.

La verdad es que el muy cabrón tiene buena pinta. Diseñado de cero para olvidarse de conceptos como particiones y similares dicen, en ZFS tienes un "pool". Vamos, un monton de espacio. Repartido entre particiones, discos, como te de la gana. Y de ese espacio, coges el espacio que quieras para crear un sistema de archivos. Añades un disco y lo metes en el "pool". Y aparentemente todos los sistemas de archivos comparten espacio del pool hasta que se agote, no hay que "darle tamaño", tienes quotas y "reservations", pero es totalmente opcional. O algo asi, manejas sistemas de archivos con la flexibilidad propia de manejar directorios. El caso es que no es como los volumenes, no tienes que preocuparte de "preasignar espacio" al sistema de archivos. Puedes crear, extender. todo sin tocar ni un solo archivo de configuracion (en solaris el punto de montaje se guarda en el sistema de archivos y te libras del fstab, en linux ext3 tambien soporta guardar esa información pero nadie lo utiliza como medio para quitarse el fstab de en medio). Dicen que tareas de 40 minutos se reducen a 10 segundos y me lo creo. Esto está claramente orientad a la compra de esa compañia de almacenamiento por la que sun pagó recientemente unos miles de millones de dolares. Sun se mete al mercado de "storage" de lleno.

Es un sistema de archivos "copy-on-write". Eso quiere decir que cuando escribes a un archivo, no se reescribe sobre el mismo archivo (dando oportunidad a que haya corrupcion) sino que se escriben los datos en un sitio vacio del sistema de archivos. Una vez copiados esos datos, se cambia de manera atómica la estructura a la que apuntan los datos. De esta manera, el journaling se hace casi innecesario (o innecesario?) y se impide que el disco pueda estar nunca en estado inconsistente, que lo hace mas veloz. O asi creo que es la historia esta. De hecho, es que ZFS no tiene fsck. No lo necesita.

Snapshots infinitos, sin limite de archivos o de directorios..etc etc. Ahora bien, una cosa es ue sea un buen sistema de archivos, y otra cosa es tragarse todo el marketing elitista de Sun. Ejemplo: En este blog habla de un benchmark que hacía a la máquina arrastrarse con UFS y que con ZFS iba a las mil maravillas. Y al final la conclusión del tipo es que las peticiones de I/O de ZFS tienen "deadline" y prioridad. Pues vaya con Solaris, digo yo. ¿Resulta que añaden el concepto deadlines ahora y no solo eso, sino que lo hacen solo para ZFS?

Señor bendito, que Linux 2.6 trae esas dos cosas de serie, y las trae en una capa por encima del de sistema de archivos, haciendo que funcionen con cualquier sistema de archivos. Para los que no tengan idea de como va el tema en Linux 2.6, la parte que se encarga de reordenar y mandar I/O's a los drivers - el famoso "algoritmo del ascensor" - es totalmente modular.

El "io scheduler" por defecto es "anticipatory scheduler" que entre otras cosas implementa el concepto de deadline de ZFS, que consiste simplemente en que las peticiones I/O sincronas de lectura (las escrituras de un proceso se pueden retrasar en el cache, las lecturas son siempre sincronas) tienen una "deadline" de manera que pasado un tiempo esas peticiones se sirven a la fuerza. Eso garantiza "calidad" y que un proceso no se quede eternamente esperando. Calidad de servicio, vamos.

Y luego esta el CFQ, que implementa prioridades I/O. A pesar de la escasísima repercusion que ha tenido este scheduler en la comunidad linux, es tan maravilloso como suena: Puedes coger un proceso y darle menos o mas "prioridad I/O", con lo cual puedes decidir que procesos tienen derecho a mas o menos MB/s. Puedes decir que apache tenga mas prioridad que nadie para que un updatedb no te tire el servidor web y cosas asi.

¿Diferencia con Solaris? Que en linux estos "io schedulers" funcionan hasta con sistemas de archivos FAT. Se implementa en el lugar correcto. Por si fuera poco, esta parte del kernel es tan modular, que no solo permite varios: Permite cambiarlos al vuelo (cat/echo /sys/block/hda/queue/scheduler). Y permite utilizar uno diferente para cada dispositivo (un disco SCSI necesita diferente gestor IO que un lapiz USB). Y permite - ojo - hacer cada io scheduler modular, y insmod/rmmodearlos, o crear tu propio IO scheduler y cargarlo como modulo y hacer que lo use tu disco para probarlo, y descargarlo y volver a cargarlo si estás desarrollando, y cambiarlos y...

Vamos, que ZFS == acojonante como sistema de archivos, pero me sigo quedando con linux como sistema operativo

15 de noviembre de 2005

La Hora Hache y la guerra de los medios

Me estoy volviendo últimamente adicto al programa de Eva Hache de Polancovisión. Sea por una cosa o por otra, me encanta verlo, pero lo que más me ha gustado hoy ha sido las sección titulada "la guerra de los medios" y la entrevista de la tal Marta Nebot (la tía buena)

Me ha hecho remontarme a los tiempos de CQC, donde se decían las cosas a "atacar". En la entrevista de la Martita Nebot ha escogido un artículo (uno que dice que las mujeres tienen los mismos derechos que los hombres en todo) y se ha puesto a preguntarle a políticos (Carod Rovira, Mas, etc) que si el artículo era de el estatuto (es curioso como los pro-españolistas anti-estatuto de turno dicen estatut sin cortarse ni un ápice) de cataluña o de la constitución. Ahí se veia desde unos cuantos politicos (incluidos algunos catalanes) que eran incapaces de decir si era de uno o de otro (eso si, evadiendo muy bien la respuesta) a otros que no dudaban un momento en decir que era del estatuto.

Pero aun mejor ha sido la sección "guerra de los medios". Cortes de radio y televisión con lo mejor de lo mejor de un lado y otro, incluyendo una muy divertida de un locutor de la Cope en la propia Cope, poniendo a parir a Losantos así de repente y sin venir a cuento, diciendo que su intervención esa mañana le habían dado ganas de vomitar y otras lindezas. Y la tipa del programa diciendole que no iba a consentir que insultara a un compañero de la propia Cope y que se saliera, y el tio diciendo que no eran insultos, que era una opinión, y que por qué no se salía ella. Un teatro, yo no sabía que Losantos tenía enemigos en casa (aunque personalmente no me extraña, con la cantidad de sandeces que suelta)

Y lo mejor de todo: Que lo ponen como anécdota, y ponen casos tanto de un lado como el otro, buscando mas el sacar un par de minutos de risa para el programa a costa de la tropa de imbéciles que controlan los medios mas que preocuparse del tema en si. Como digo, me ha recordado (gratamente) a CQC: Las entrevistas con preguntas picantes a los políticos a la salida del congreso donde los propios políticos tienen la oportunidad de dejarse en ridículo o no en vez de depender de lo que dicen cuatro tertulianuchos de tres al cuarto....etc etc. Lo necesitaba.

(Y si, ya se que se pone en Polancovisión y que el otro día entrevistaron a Carrillo, que la gente se ahorre los "oh, es que te manipulan y no te das cuenta y yo si" que tanto abundan en este tipo de posts, que si quisiera dejar que me manipularan vería los telediarios y tertulianos matutinos que es donde verdaderamente se dan esas cosas. La Noche Hache es un programa genial y punto)

10 de noviembre de 2005

DVD de sarge en el mundo

Como ya sabrá mucha gente, El Mundo va a incluir un DVD opcional este viernes (o sea, mañana) junto con otro DVD de noseque por 4.96 euros

Qué gran error. Quiero decir: Si vas a ofrecer una distro de linux a miles de potenciales usuarios novatos, lo peor que puedes hacer es darles debian. Se agradecen las buenas intenciones de El Mundo y todo eso, pero es que esto va a perjudicarnos. ¿Como coño va a pensar la gente que Linux puede sustituir a Windows?

Con Debian van a pensar lo contrario, que Linux es muy dificil y que es mejor seguir usando Windows. Debian es una gran distro, yo lo uso. Pero joder, estamos hablando de gente que no tiene ni puta idea de informática en su gran mayoría. El DVD de knoopix, ubuntu, guadalinex....por favor, cualquier cosa menos Debian

Puedo oir los lamentos de Sony desde aquí

El Estado de california acaba de denunciar a Sony por su rootkit (rootkit que viene en los CDs de musica de sony puesto ahí por la propia sony y que abusa de los derechos de los usuarios, etc), con posibilidad de otra denuncia a nivel de todo estados unidos, con posibilidad de que los italianos tambien se unan y esperemos que se unan mas paises

Por si fuera poco, el rootkit de sony podría estar mandando información personal a Sony, spyware en toda regla. Y todo esto aderezado con la interesante noticia de que los programadores de virus han empezado a utilizar el rootkit de sony para esconder sus virus.

Todo esto solo lo sufren los usuarios que querían comprar CDs originales de música. Los que se lo bajan de internet estan intactos. El sentido común me anima desde aquí a aconsejar a la gente que utilize su derecho a copia privada para bajarse música de sony del emule. Comprar CDs de música de Sony BMG a día de hoy es peligroso. Me alegra saber que el último CD de Sabina que tengo aquí a mi vera no parece tener nada (Joaquín cabrón, cambia de discografica :P) hasta que se sepa que los CDs de Sony son seguros (hay otros tipos de software DRM en otros cds de sony) y el usuario pueda asegurarse de que no hay nada malo en ellos

7 de noviembre de 2005

Odio RSS

A veces me pregunto por qué hay tanto software odiable. La verdad es que la informática es una rama muy pesimista, te dedicas la mayor parte del tiempo a pensar en lo mucho que odias X, en lo mal hecho que está Y, o qué cantidad de drogas y alcohol tomó la madre del desarrollador Z durante el embarazo. En fin.

En realidad no odio a RSS en si, sino a la manera en que se ha construido todo. No, en realidad lo que odio es el protocolo HTTP 1.1. Oh, si, COMO LO ODIO, lo odiamos mucho ¿si?. Si, lo odiamos con todas nuestras fuerzas. ¿Por qué los agregadores de RSS tienen que BAJARSE TODO EL MALDITO RSS cada vez que quieren mirar si hay actualizaciones, maldita sea? ¿No sería más sencillo que el agregador pudiera mirar algo tan simple como "fecha en la que se actualizó por última vez expresada en tiempo unix"? ¿O algo como "hash de el archivo RSS que me sirva para indicar si debo bajarle o tengo suficiente con mi versión cacheada que es exactamente igual"? Cada vez que mi akregator mira a ver si hay actualizaciones de blogs se baja todos los RSS uno por uno, comiendome el ancho de banda de mi 56k.

No es cosa de broma. Se han escrito artículos en todo internet preguntando si RSS scala y si no podría colapsarse: Muchos sitios reciben cada hora visitas de miles de agregadores que ponen a su sitio en una situación similar a la de un ataque DOS. Echan la culpa al RSS, pero de que tiene la culpa RSS? RSS no "notifica" actualizaciones, solo describe datos y no puede hacerlo de mejor manera. Se habla de que algunos agregadores pasan de usar cabeceras HTTP del tipo "if-modified-since". Ah, las maravillas de HTTP.

En realidad, HTTP 1.1 tiene todo un bendito y largo capítulo al tema de cacheo. Tambien tiene soporte para decir el md5, porque podrias bajarte incorrectamente un html y pensar que tienes la ultima version. Claro, que nadie lo utiliza a efectos de cache, y el capítulo de cacheo habla sobre todo de fechas, que es absurdo para la mayor parte de los casos (es útil sin embargo para cosas como archivos gigantescos de los que hacer un md5 sería prohibitivo)

En mi opinión, lo ideal es que a HTTP se le pudieran dar instrucciones del tipo "dame el último tiempo de modificacion de tal página", o aun mejor "enviame el objeto foobar si su ultima fecha de modificacion no es tal", para ahorrar una ida y vuelta y ahorra latencia (ya de paso, no estaría mal que el puto pop3 tuviera una instruccion "retr and dele"). De hecho, creo que http tiene un campo de ese tipo, pero a saber que servidores lo implementan por defecot, que navegadores le hacen caso, y lo que es mas importante: ¿Por qué no han sacado una nueva versión que lo haga obligatorio? Permitiría que el navegador tuviera un cacheado perfecto: Estoy cansado de que firefox/ie/opera se "vuelva a bajar" cosas cada vez que visito páginas. Es más, estoy cansado de que cuando visito una página, y no ha cambiado NADA, tenga que bajarme la página DE NUEVO en vez de regenerarla completamente desde el cache que es lo que debería ocurrir.

Parte del problema es que http es un protocolo "sin estado": Pides una cosa, y el servidor ya no se acuerda de ti, no hay concepto de "sesion". Y que me perdonen si digo un sacrilegio, pero me parece una mierda que lo sea. ¿Por qué, que tiene de ventaja? HTTP tiene muy poco que ver con la naturaleza real de la web, la "web" lo único en lo que consiste es en leer archivos, nada más. Una especie de NFS, de sistema de archivos remoto. Si plan9 hubiera tenido éxito por cierto, http no seria necesario: Simplemente "montarias" el sistema de archivos del servidor en el espacio de nombres de tu proceso, y el navegador leeria archivos como si estuviera en local, dejando que el sistema los traiga y cachee en tu disco duro. ¿Necesitas mandar datos? Pues escribes a un archivo determinado, punto. La naturaleza "sin estado" de HTTP es la que obliga a los diseñadores web a añadir cadenas raras al final de las URLs para identificar a los usuarios entre diferentes cargas de páginas, para poder saber quien coño son.

El que HTTP sea un protocolo sin estado es tan absurdo que en la versión 1.1 se inventaron algo de conexiones persistentes para cambiarlo que supongo que estará basado en esto y luego se sacaron de la manga el keep-alive. Por supuesto: Eso no hace que HTTP deje de ser un protocolo "sin estado", sigue siendolo en el fondo a pesar de que le hayan incluido un parche. ¿Por que no se rediseño el estándar? Lo lógico e ideal, es que si yo voy a slashdot.org, me bajo la página, cierro el navegador y vuelva a la misma página, y que el navegador simplemente pida al servidor la información de fecha de ultima actualizacion de la pagina y de las imagenes en la página, y punto. El hecho de que tengamos una "recarga forzada" en los navegadores es el mejor signo visible de la debilidad del protocolo que utilizan. Y ahora mismo iba a empezar a pensar en javascript + css + html, el no-demasiado-óptimo sistema de recuperación de paquetes de TCP....oh dios...internet es un castillo construido con cimientos de arena sobre de una montaña de mierda.

5 de noviembre de 2005

Google pagará por instalaciones de firefox

Desde hace un tiempo estaba claro que Google estaba interesado en el éxito de Firefox. El fracaso de microsoft le beneficia y el soporte de estándares de firefox le interesan.

El caso es que aparentemente, Google ha actualizado adsense, y tiene una cosa llamada referrals. Bueno, pues google pagará 1US $ por mandar a un referral a una descarga de firefox + barra de google

En otras palabras, google paga porque la gente se descargue firefox. Y lo hace sin mover un solo dedo: En vez de promocionarlo ellos, se vale de su adsense para que todas las webs que lo usan lo promocionen ellas mismas. El único incentivo es el económico. Gracias, google.

4 de noviembre de 2005

bienvenido gcjwebplugin, adios VM Java de Sun

Pues acabo de descubrir que en debian tengo el plugin de la implementación de java de classpath/gcj.

Eso significa, que con un apt-get install gcjwebplugin y tan solo 5 megas de descarga, puedo ejecutar applets java sin tener que recurrir a tocar la VM de sun. Y por unos pocos megas mas, java-gcj-compat te instala el resto de programas y enlaces simbolicos y scripts necesarios para que al ejecutar "java" o cualquier comando de java, como si tuvieras instalado la VM de sun

Y lo más importante: Es libre. Y las ventajas de ser libre no son solo filosóficas. Gracias a ser libre, gcj permite que java sea realmente multiplataforma, porque gcj permite usar java en literalmente cualquiera de las plataformas que soporta GCC. A diferencia de la de sun, que aplica el cuento de la "multiplataforma" solo a las plataformas que a ellos les da la gana soportar, entre las cuales no se incluye sin ir mas lejos linux para ppc o sparc, o los BSD.

Classpath tiene un 95% de la api de Java 1.4 implementada (ya tienen el soporte de generics de 1.5 y demas implementado tammbien), que no está mal. Por supuesto, eso no implica que este correctamente implementado o que sea rápido, pero la idea es que está bastante bastante avanzado. De hecho no es ningún secreto que en fedora lo utilizan para compilar nativamente eclipse y la parte de java que usa openoffice. Y a diferencia de sun, que implementa su propia interfaz, classpath utiliza gtk. Lo cual permite que a diferencia de sun, me salga el dialogo de texto de gtk al hacer click con el boton derecho y que en la de sun no me salga nada

Y lo de la rapidez, puedo confirmar (gracias a uno de los pocos benchmarks online que me han funcionado) que es mucho más lento. Cosa que no debería sorprender a nadie, no es raro que un proyecto (que por cierto está apoyado y pagado principalmente por redhat) que ha empezado hace poco y que está ocupado en replicar la api sea mas lento que una máquina virtual que ha sido el niño mimado de una de las multinacionales mas importantes del sector con millones de dolares a sus espaldas y más de 10 años de desarrollo (y que a pesar de eso, consume mas memoria que un viper gasolina). La mayor lentitud en el benchmark que he probado ha sido el lanzar y recoger 1.000.000 excepciones: 36 soberanos segundos frente a 0.36 segundos. Sin embargo, es el doble de rápido que el java de sun en lanzar 3 threads y cambiar de contexto 10000 veces cada uno: 0.029 frente a los 0.043 de sun. Tambien parece ser más rapido algo relacionado con el recolector de memoria.

3 de noviembre de 2005

¿Alguien ha visto la reputación de Sony por alguna parte?

En Augcyl ya trató el tema Gue Rivero, el tema de una especie de rootkit creado por una compañia que pone Sony en sus dvds y que el genio de sysinternals analizó en profundidad.

Pues me alegro saber que las compañias de antivirus lo están añadiendo a sus bases de datos como virus

Y hacen una observación muy inteligente: El programita en cuestión viene en DVDs "legales". En otras palabras: Estan intentando vigilar a las personas que compran sus dvds legalmente. Lo cual es absurdo. A quien teóricamente quieren vigilar es a las personas que no compran DVDs de forma legal, es decir, a las personas que nunca van a tener ese programita instalado.

Una razón más para ejercer el derecho a la copia privada: No es solo que los medios de distribución que utilizan se están quedando obsoletos y que los precios no son lo que debieran, es que ademas te medio joden el ordenador. Y querrán que compremos sus DVDs. Manda huevos, como diria un politico

27 de octubre de 2005

"¿Y tu, que algoritmo de congestión TCP usas?"

Pues esa pregunta es buena. Porque al recopilar información sobre los cambios que se producen en el kernel, me enteré que Linux desde 2.6.13 tiene más de uno. Y no solo eso, sino que tambien se puede - ojo al dato señores - seleccionar un algoritmo de congestión diferente para cada socket (con setsockopt())

Y a través de un artículo de LWN, me he enterado de qué algoritmos hay disponibles, y las propiedades que tiene cada uno. Total, que el que se compila por defecto parece estar orientado a redes rapidillas (adsl y demas supongo). Asique he ido a la configuración del kernel y he desactivado ese y activado el "Westwood". No he hecho mediciones pero teóricamente debería ser más óptimo para un triste modem de 56 K (o eso creo)

(Nota: Se puede seleccionar el algoritmo por defecto de entre los compilados en /proc/sys/net/ipv4/tcp_congestion_control, para que no diga nadie que me contradigo a mi mismo cuando escribí eso de que "la gente no debería recompilar los kernels ellos mismos" :P)

26 de octubre de 2005

dos cosas

Las dos cosas interesantes que se están cociendo en el kernel ahora mismo y que en mi humilde opinión hacen babear por lo que podrían llegar a hacer: A CLOCK-Pro page replacement implementation y Adaptive file readahead

El uno parece ser un algoritmo de reemplazo moderno (publicado en Usenix en 2005, según escribe Rick van Riel no ha habido algoritmos mejores que fueran implementables en sistemas operativos de propósito general hasta el 2002, lo que hace pensar que Linux está siendo bastante "innovador" en este aspecto, no todo en el mundo de los sistemas operativos se inventó hace 30 años). Y del otro hablan mejor los números: In fact, Wu claims results which are "pretty optimistic." They include a 20-100% improvement for applications doing parallel reads (Nota: Este debería ser el caso de un servidor web apache/thttpd/etc sirviendo multiples peticiones de páginas estáticas simultaneamente), and the ability to run 800 1KB/sec simultaneous streams on a 64MB system without thrashing

24 de octubre de 2005

Adios, Tarja

Los que sepan quien es Tarja Turunen sabrán a que me refiero. En la página de nightiwsh (que ayer estaba caida por la avalancha de visitas) se puede leer la carta que el resto del grupo la ha entregado al final de la gira. La hechan del grupo

Para los que no sepan quien es Tarja Turunen, decir que es una de las mejores cantantes que hay por ahi de su categoría y no es necesario decir mas del tema, y el que piense que lo digo por ser fan de ellos es libre de bajarse un directo (los discos siempre se retocan) de ellos para comprobar que no es en broma, o bajarse una canción cualquiera del disco, como esta

Como nota curiosa, las agencias de prensa finlandesas, francesas, la propia televisión finlandesa, se han hecho eco del evento. Eso aquí en España no lo veremos en la puta vida, porque aquí los grupos del tipo de nightwish ("jevis") no tienen cabida (del último disco, el que mas éxito internacional ha logrado despues de otros muchos no menos buenos, ponian un single en los 40, demos gracias a dios) y la mayoría de gente piensa que son malos. Como si se pudiera determinar la calidad de un grupo por su estilo, o como si existiera algun estilo en el mundo que no tenga grupos buenos, o como si existiera algun estilo en el que todos los grupos sean buenos. Allí en su tierra natal en Finlandia, quedaron en una ocasión entre los 3 finalistas para ir a Eurovisión a representar a su pais, y eran uno de los grupos mas escuchados del pais, alcanzando puestos altos en las listas de ventas y tal. Pero como acabo de decir, aquello no es España

microsoft shell vs unix shell/python/perl

Ars technica ha publicado una guia bastante detallada de 13 páginas explicando que es MSH (el próximo shell de microsoft)

Le da mil vueltas a bash/ksh/zsh y derivados, por supuesto (no es dificil superar a una tecnología que lleva 30 años estancada, obsoleta en muchos aspectos y sin muchas expectativas de mejorar - bueno, zsh al menos como "shell interactivo" tiene cosas interesantes, pero bash siempre ha sido deprimente incluso comparandolo con otros shells unix), y entra a competir con python, perl & friends, e incluso parece integrarse con .NET.

En la comparación con estos últimos ya no se como saldrá, pero si que se puede decir una cosa: MSH es un shell, igual que bash, no un simple "interprete de scripts" que es lo que son python & perl (aunque se pueden usar en modo "interactivo", dejan mucho que desear como "shells de uso diario y administración del sistema", están diseñados para ser usados desde bash no para sustituirlo). Tal como yo lo veo, ahí está el problema: En unix, estamos acostumbrados a programar cosas en python y "ensamblarlas" a través de tuberias y construcciones de bash. Que no está mal, pero las tuberias no son la solucion a todo: cuando para conseguir los datos de algo en bash para cualquier cosa necesitas hacer "HAZME_EL_TERMINAL_MAS_GRANDE=100 dpkg -l | cut -d ' ' -f 3" está claro que algo falla. Sería fantastico si en bash pudiera hacer kudzu.probe() para extraer los datos del hardware instalado y manipular esos datos en la propia linea de comandos del sistema para administrar alguna cosa en vez de crear algun script que lo haga y ejecutarlo desde el shell con "python script.py"

Afortunadamente, hay alternativas. El problema, como siempre, es hacer que la gente las use, que sustituyan a bash por defecto como shell (y al que se le ocurra decir que "python es lento" que se pregunte primero si los scripts que usamos hoy están orientados a tareas de "alto rendimiento"), que puedas hacer de todo en ellas sin tener que recurrir a "ayudas de terceros", etc etc. En cualquier caso, un servidor va a hacer apt-get install ipython

19 de octubre de 2005

inotify

El otro día en un thread sobre inotify se leia una cosa interesante. El jugo de inotify es monitorizar cosas sobre inodos. Entre otras cosas, puedes decirle a inotify, con IN_DELETE_SELF, que te avise de cuando un archivo va a ser borrado

Y aquí venía el problema curioso. Inotify vigila a los inodos, y como buen sistema unix, en linux la ruta "/foobar/archivo" no es mas que un "enlace" a un inodo. Puedes borrar ese enlace a ese inodo para borrar el archivo, puedes hacer que apunte a otro inodo, pero el inodo antiguo seguirá ahí y puedes seguir escribiendolo o leyendolo (razón por la cual en unix es posible sobreescribir un archivo mientras está abierto, ej: al actualizar paquetes)

Y ahí está el problema: Si quieres "espiar" con inotify y con IN_DELETE_SELF el momento de borrado de un archivo, te encontrarás con que despues de hacer un "rm" inotify no notifica nada porque el inodo aun existe. El problema es que en unix no puedes monitorizar el borrado de un archivo monitorizando inodos (y por tanto, con inotify) - unix no funciona asi. Asi que como bien dijo linus, la propia existencia de IN_DELETE_SELF es estúpida. No es un defecto de unix ni de inotify: Es una consecuencia del diseño de unix, asi que como dice linus en el mensaje, si quieres monitorizar el borrado de un archivo no tendras mas remedio que monitorizar al directorio. Aunque parece absurdo a primera vista (al menos a mis ojos), esa es la manera "correcta" de hacerlo en unix. Me parecia algo curioso para comentar.

17 de octubre de 2005

¡por fin! escritura para NTFS

Anton Altaparmakov es el PUTO AMO. En el último anuncio del -mm ha anunciado que ya tiene soporte COMPLETO para escritura en NFTS (le falta el soporte para crear y borrar archivos, algunos problemas con archivos fragmentados) pero supongo que si ha llegado hasta este punto, es cuestión de tiempo...

Y digo PUTO AMO porque hay que tener huevos, muchos huevos, para implementar un sistema de archivos complejo como lo es NTFS sin NADA DE DOCUMENTACION de parte del autor. Como referencia, el soporte de UFS para sistemas de archivos de freebsd, que tiene el codigo 100% abierto y es mucho mas sencillo que NTFS y muy parecido en diseño a ext2, solo tiene soporte de lectura, y a saber si tendrá el de escritura algun dia. Lo dicho, el puto amo.

16 de octubre de 2005

solaris vs freebsd vs linux

De eso va mas o menos interesante artículo que compara los kernels de solaris, freebsd y linux desde un punto de vista constructivo (que no es poco). Algunas cosas son curiosas

Solaris has support for a "fixed priority" class, a "system class" for system threads (such as page-out threads), an "interactive" class used for threads running in a windowing environment under control of the X server

En Linux, Ingo Molnar propuso cosas parecidas (añadir algo que permitira marcar a las X & friends como "interactivos" para poder tratarlos de manera especial, o poner las X a prioridad -10 para olvidarse de los problemas). Linus lo rechazó frontalmente: In short, you're taking a very NT'ish approach - make certain programs run in the "foreground", and give them a static boost because they are magically more important. And you're ignoring the fact that the heuristics we have now are clearly fundamentally broken in certain circumstances

Esta es la misma la razón por la que de momento Linux no incluye (de momento) la capacidad de cambiar de tipo de scheduler "en vivo" como hacen solaris y otros unix "serios" (que haberlos haylos): En linux se cree que si tienes que recurrir a eso es porque el scheduler principal tiene un bug, y que lo mas logico es arreglar ese bug, no "workaroundear" el problema añadiendo complejidad. Supongo que es ese tipo de actitud la que hace que prefiera linux a los demás.


Linux divides machine-dependent layers from machine-independent layers at a much higher level in the software. On Solaris and FreeBSD, much of the code dealing with, for instance, page fault handling is machine-independent. On Linux, the code to handle page faults is pretty much machine-dependent from the beginning of the fault handling. A consequence of this is that Linux can handle much of the paging code more quickly because there is less data abstraction (layering) in the code. However, the cost is that a change in the underlying hardware or model requires more changes to the code

Igual que esta. Linux tendrá mas codigo dependiente de máquina, pero sacrificar el rendimiento de algo tan importante y tan utilizado por ahorrar esfuerzos a la hora de programar es algo que no va con el "espiritu linux"


Y la mejor de todas: Solaris, FreeBSD, and Linux are obviously benefiting from each other. With Solaris going open source, I expect this to continue at a faster rate.

14 de octubre de 2005

hay que saber perder

Acabo de leer en el blog de Rusty Rusell (el creador de netfilter) una gran frase, en el que destaca las virtudes positivas del entorno "arisco" que hay en el kernel y la poquísima tolerancia que hay frente a la basura (actitud que no se ve en "otros proyectos", y así les va, haciendo rondas de optimización y de reducción de memoria a su software años despues de haber sacado la primera version estable porque ya no entra mas basura en el cubo):

"One thing I gained from working on the kernel: a good sense of when code is crap. If my code is good, it is not because I am smart, but because I refuse to release stuff which stinks, so I'm forced to spend time cleaning it up. The harsh environment of the linux-kernel mailing list trains you to do this yourself

I'm reluctant to harshly criticize the code of others, because I am aware how hurtful such words can be. On the other hand, without such harshness, you end up, say, using a helper thread in the implementation of a library. Not because you're stupid, but because you haven't developed a pavlovian shudder at the thought of releasing such a thing"

Y para los que no lo conozcan, aquí esta la "netfilter song" de rusty que le dió por postear un día como respuesta a un email que preguntaba como funcionaba netfilter:

> The biggest difference is that INPUT chains NOW *behind* "routing
> decision".
>
> So what is the real path of packet?
>
> Rusty?

Rusty reading netfilter:
     ______
    / /  \    /  o  o     \ .____, /
    \______/
  ^^^      ^^^
[TABqwertyiop[]\]

My ASCII art sucks, I know.  Perhaps I should try a different form of
expression:

  When a packet on a network
  Enters Linux from a NIC,
  Or PPP, ISDN,
  Or even via SL/IP,

  It goes right into net_bh,
  Which sees it is IP,
  And hands it via ptype->func()
  To old ip_rcv().                         [pron: `EYE-PEE receive']

  This calls the PRE_ROUTING hook,
  Where ipfwadm was,                       [pron: `EYE-PEE-FWADM']
  And ipchains lived here as well,
  But not iptables, 'cause...

  PRE_ROUTING is for NAT NAT NAT,
  Redirection and so on,
  Inadaquate for filtering,
  So iptables is gone...

  To LOCAL_IN, the one true hook,
  Where filtering ought to be,
  Because we know this very box,
  Is its destiny.

  On the way out, it's just the same,
  'Cause filtering now takes place
  As local packets leave the box,
  In LOCAL_OUT, with grace.

  But what, you ask, are we to do
  About packets passing through?
  Where should we now filter them
  Please give us this one clue?

  Not in PRE_ROUTING nor in POST,
  We don't need three ways here,
  The one true place to filter these,
  Is the FORWARD hook, it's clear.

  The FORWARD hook is just the same,
  But we've added just one thing,
  You get incoming interface,
  As well as outgoing.

Chorus:

  iptables is so cool,
  It makes my packets sing,
  That Rusty he is one hot coder,
  OOPS: my box is crashing...

   Rusty.

10 de octubre de 2005

Changelog del kernel para humanos

(Y si, pongo changelog y no "registro de cambios" :P)

Pues asustado/preocupado por la falta de un changelog decente para linux, me dió por recoger información de varias fuentes: "post-halloween" de Dave Jones, "2.6 status" de Guillaume Boissiere, sección del kernel de LWN.net, google, changelogs oficiales, y seguir día a día todo lo que va a pasando a partir de ahora en el gracias a la maravillosa interfaz web de git con RSS incluido.

Y con toda la información que ha salido de ahí he creado http://wiki.kernelnewbies.org/LinuxChanges. Que todo el mundo coincidirá que es genial y útil, no porque sea buena sino porque no hay nada semejante a esto (con el permiso de LWN)

4 de octubre de 2005

Daría mi vida por.....

Mientras escribía un script que automatize el proceso de actualizar y compilar automaticamente los 3 ó 4 proyectos de los que me gusta "tirar de CVS", y acordándome de que el protocolo de red de Plan 9 devuelve los errores en forma de cadenas de error y no "códigos de error", me he dado cuenta de una cosa: Daría mi vida por que los comandos Unix devolvieran cadenas de error y no absurdos numeros.

Necesito saber qué código de retorno devuelve CVS cuando no hay ninguna actualización en el CVS, y sinceramente me vendría muy bien que el script tuviera algo del estilo: "if cvs update = "No updates found"" en vez de un absurdo "if cvs update = 0".

29 de septiembre de 2005

los estándares no importan

No lo digo yo, lo dice Linus Torvalds. Y la cosa es que tiene toda la puta razón. Un par de emails cojonudos de él sobre el tema, el primero de hoy y el otro de hace años...(si, guardo los emails que me parecen interesantes). Pero por si alguien no se los lee, no puedo evitar resaltar esto del segundo email: "Call me cynical, but I believe in standards papers just about as much as I believe in the voices in my attic that tell me to kill the Queen of England"


On Thu, 29 Sep 2005, Arjan van de Ven wrote:
> 
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)

How we do the SW is indeed up to us, but I want to step in on your first 
point.

Again.

A "spec" is close to useless. I have _never_ seen a spec that was both big 
enough to be useful _and_ accurate.

And I have seen _lots_ of total crap work that was based on specs. It's 
_the_ single worst way to write software, because it by definition means 
that the software was written to match theory, not reality.

So there's two MAJOR reasons to avoid specs:

 - they're dangerously wrong. Reality is different, and anybody who thinks 
   specs matter over reality should get out of kernel programming NOW. 
   When reality and specs clash, the spec has zero meaning. Zilch. Nada.
   None.

   It's like real science: if you have a theory that doesn't match 
   experiments, it doesn't matter _how_ much you like that theory. It's
   wrong. You can use it as an approximation, but you MUST keep in mind 
   that it's an approximation.

 - specs have an inevitably tendency to try to introduce abstractions
   levels and wording and documentation policies that make sense for a 
   written spec. Trying to implement actual code off the spec leads to the 
   code looking and working like CRAP. 

   The classic example of this is the OSI network model protocols. Classic 
   spec-design, which had absolutely _zero_ relevance for the real world. 
   We still talk about the seven layers model, because it's a convenient 
   model for _discussion_, but that has absolutely zero to do with any 
   real-life software engineering. In other words, it's a way to _talk_ 
   about things, not to implement them.

   And that's important. Specs are a basis for _talking_about_ things. But 
   they are _not_ a basis for implementing software.

So please don't bother talking about specs. Real standards grow up 
_despite_ specs, not thanks to them.

  Linus


Y....



On Mon, 22 Nov 2004, Len Brown wrote:
> 
> I agree that the system should work properly even if the legacy device
> drivers are broken.  Please understand, however, that the legacy device
> drivers _are_ broken.  The BIOS via ACPI clearly tells them if the
> devices are present or not, and Linux isn't yet listening.

I really disagree.

I realize that you like ACPI, or you would have shot yourself long long 
ago.

But I have a totally different view on things. To me, firmware is not 
something cool to be used. It's a necessary evil, and it should be avoided 
and mistrusted as far as humanly possible, because it is always buggy, and 
we can't fix the bugs in it.

Yes, the current ACPI layer in the kernel is a lot better at working
around the bugs, and it's getting to the point where I suspect Linux
vendors actually decide that enabing ACPI by default causes fewer problems 
than it solves. That clearly didn't use to be true.

> ACPI-compliant systems have three types of interrupts:

Stop right there. 

"ACPI-compliant systems". The fact is, there is no such thing. There are 
systems that users buy, and they are not "ACPI compliant", they are "one 
implementation of ACPI that was tested with a single vendor usage test".

Call me cynical, but I believe in standards papers just about as much as I 
believe in the voices in my attic that tell me to kill the Queen of 
England. 

Papers is so much dead trees. The only thing that matters is real life.  
And like it or not, real life does NOT implement standards properly, even
if the standards are well written and unambiguous (which also doesn't
actually happen in real life).

> If somebody bolts motherboard hardware on and doesn't tell ACPI about
> it, then they need to disable ACPI, which _owns_ configuration of
> motherboard devices when it is enabled.

No. The only thing that owns the motherboard is the user. ACPI shouldn't 
get uppity.

> The damn good reason is that doing otherwise breaks systems.

And not doing it breaks systems.

See a pattern?

This is why I don't trust firmware. It's always buggy. 

  Linus

21 de septiembre de 2005

pa que luego los de solaris digan de linux

En la última actualizacion de opensolaris tienen una novedad interesante:

'intrd' arrives. intrd is a daemon which evaluates whether or not interrupts on the system are properly balanced between CPUs. If needed, intrd reassigns interrupts from CPU to CPU. [5017144]

Curioseando la base de datos de bugsde solaris, sus clientes llevan pidiendoselo desde el 2000, y ademas lo piden con insistencia

Curiosamente, linux tiene algo así desde el 2004. Digo curiosos porque me sorprende ver algo en linux en el terreno de servidor que otros que estaban ahi no tuvieran ya. Creo que NT tampoco tiene algo similar.

La otra cosa curiosa es que lo han implementado en un script de perl

20 de septiembre de 2005

¿vista mueve el subsistema de sonido a espacio de usuario? Nah...

En Osnews han destacado una entrada del blog de Larry Osterman (uno de esos programadores de microsoft que SI que hacen las cosas bien) en el que habla de como han movido cosas de audio del kernel al espacio de usuario

En osnews lo han tomado como que "han movido todo el subsistema de audio a espacio de usuario". ¿Todo? Uh...

"The first (and biggest) change we made was to move the entire audio stack out of the kernel and into user mode. Pre-Vista, the audio stack lived in a bunch of different kernel mode device drivers, including sysaudio.sys, kmixer.sys, wdmaud.sys, redbook.sys, etc. In Vista and beyond, the only kernel mode drivers for audio are the actual audio drivers (and portcls.sys, the high level audio port driver)"

Si uno se fija en el post de larry, no se dice exactamente que se estén moviendo todo fuera del kernel: Los drivers siguen dentro: "the only kernel mode drivers for audio are the actual audio drivers"

¿Entonces que han sacado del kernel y a que viene la noticia, si los drivers siguen ahi? Pues viene a que por lo visto (y no era desconocido), en los windows de hoy, el subsistema de sonido en el kernel no tiene solo drivers: Tiene drivers y más cosas. Ejemplo: Ese "kmixer.sys" del que habla Larry. Equivalente al dmix de ALSA - excepto que el dmix de alsa se implementa en las librerias de espacio de usuario de ALSA. Es decir, no es que Vista este "moviendo todo el subsistema de sonido fuera del kernel". Es que está sacando del kernel cosas que no deberian estar ahí. En otras palabras, están dejando en el kernel básicamente lo equivalente a ALSA. Tal como yo lo entiendo.

Y hay otro detalle muy sutil, pero muy curioso: The amount of code that runs in the kernel (coupled with buggy device drivers) causes the audio stack to be one of the leading causes of Windows reliability problems.. No se que tipo de organización tiene windows con respecto a los codecs, pero los malos codecs siempre han sido fuente de inestabilidad en windows, y me temo que esté relacionado con todo esto: Con que los codecs tuvieran que tocar más internalidades de las necesarias para hacer su trabajo, y que a veces lo hicieran mal

Pero el detalle realmente sutil es este, no el anterior. En este mismo blog he escrito mas de una vez el infierno que iba a suponer para microsoft el dual core. Un driver no preparado para maquinas SMP significa un cuelgue potencial en una máquina con dual core. Y los fabricantes de hardware, cuyos programadores y clientes nunca han utilizado máquinas SMP, tienen los drivers como yo le diga a usted. Me alegra saber que no estaba equivocado, porque este comentario de ese blog lo atestigua perfectamente...:

"one of the leading causes of Windows reliability problems" - tell me about it. I had to return about 90% of audio cards I bought because the drivers simply would not work for more than few minutes of playing audio on a multiple cpu system (and I mean multiple CPU, not just HT). Mixing multiple sources when you can actually have multiple requests coming in at literally the same time proved to be beyond most hardware manufacturers' skill. The only card that worked reliably for me was an old AWE32 running Microsoft's drivers but I can't use that anymore as my current mobo does not have an ISA slot. I'm currently using a card based on VIA's Envy24-HF chip with VIA's drivers, it doesn't sound as good as some other cards but at least it does not crash my box.

Podría apostarme algo a que los desarrolladores del subsistema de audio de windows van a sentir tentaciones de poner un pedazo de punto de sincronización a la entrada del subsistema de audio para evitar que más de dos procesos puedan entrar simultaneamente en esa parte del kernel...y que dejen de echarles la bronca cuando los dualcore se usen mucho...

4 de septiembre de 2005

pensamientos matutinos

El otro día yendo por ahí por la noche con un amigo, vimos a un par de chicas que estaban sentadas a las que no conociamos de nada. Como estabamos aburridos nos pusimos a darlas la tabarra como quien no quiere la cosa (con buenas intenciones)

Recuerdo que alguien pregunto a una de ellas algo sobre un ordenador, y ella dijo que no tenía. No solo eso, dijo que no le gustaban los ordenadores. Me sorprendio la respuesta, y me puse a "interrogarla" para averiguar de donde venía ese odio, porque me sorprendía que una chica de hoy en día odie los ordenadores. Conozco a gente que no tiene ordenador porque no lo cree necesario o por lo que sea, pero no conocía a nadie que no tuviera ordenador porque lo odiara. Asi que me puse a hablar de lo útil que son cosas como el messenger, que te permiten estar en contacto con la gente, cosas que a todo el mundo le gustan, lo usen o no

Eso pensaba, pero me equivoque. Me respondió que no comprendia los ordenadores. No que no supiera usarlos o algo de esos, sino que no les "entendia", que ya había visto y probado el messenger por ahi, que los ordenadores eran demasiado complicados de usar y que para hablar con sus amigos prefería usar el telefono, que era mucho más práctico

¿Y que puedo aprender yo como "informático" de cosas como esta? No lo se, pero supongo que algo

más DRM

En slashdot han hablado de un magnífico artículo que analiza el "hogar digital" desde un punto de vista de un economista. Me gusta especialmente estos párrafos sobre DRM:

In DRM, the situation is even more chaotic. Microsoft pushes its Windows DRM; RealNetworks, which makes rival media software, has Helix; Sony has OpenMG; Apple likes FairPlay, and so on. The upshot is that consumers cannot mix online services, gadgets and software from different vendors and be sure that the content they have paid for actually works. Music bought online from Microsoft's MSN or Yahoo!, for instance, does not work on Apple's iTunes or iPod, and vice versa.

This challenge is daunting because DRM technologies should not only be compatible today, but for all eternity. Otherwise, consumers will be afraid to pay for content, and will stick with CDs and DVDs, which seem painless and safe by comparison. “If consumers even know there's a DRM, what it is, and how it works, we've already failed,” says Peter Lee, an executive at Disney. The same goes for codecs. “The user shouldn't know or care what format they're using,” says James Poder, an engineer at Comcast, America's largest cable company and broadband internet service provider, because “consumers don't want to be IT administrators for their own home.”

2 de septiembre de 2005

Mac OS X vs linux vs threads

Los de Anandtech han hecho unos benchmarks de Mac OS X vs linux como plataformas de servidor en el cual muestran lo exageradamente lento que es mac os x en ese campo: It is clear that if you plan to run MySQL on Apple hardware, it is better to install YDL Linux than to use OS X. If you need excellent read performance, the maximum performance of your server will be up to 8 times better

Pero lo mas interesante es el análisis de por qué es así. Pocas veces en una comparativa el comparador se pone a hacer un análisis detallado de porque esto es así y asá, en vez de conformarse con dar los resultados y concluir el artículo diciendo "fulanito es mas rápido". http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=7 y http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=8

1 de septiembre de 2005

escritorio y last.fm

Picado por el post de Javier Santana, yo tambien voy a poner una foto de mi escritorio (y asi, de paso, probar la cosa esta que añadieron al blogger de "subir archivos")


(Update: he puesto las imagenes como enlaces, me salian demasiado grandes y pense que podria dañar al planet) Escritorio


En el cual se pueden observar varias cosas: 1) que uso XFCE (aunque a veces cambio a KDE) 2) que en la barra de tareas, el texto del botón se sale del botón. Es un bug que me apareció al instalar GTK 2.8 (el basado en cairo, etc etc) 2) que uso sylpheed, y fuentes gigantescas para no quedarme ciego. 3) un post de un auténtico gilipollas. Jeff Merkey, el tipo que propuso a los del kernel comprarles el copyright para licenciar el kernel bajo la BSD 4) que uso amarok y que en ese momento estoy escuchando un album cuyas canciones están compuestas por uno de los mejores guitarristas de este pais


Y sobre last.fm, decir que Ramón Rey me picó, y que me he apuntado a la moda. Mi URL es http://www.last.fm/user/diegocg/ . Apuntarme fue sencillisimo, y hacerlo funcionar mucho más porque Amarok trae audioscrobbler integrado

Tambien iba a decir algo sobre como el huracán que está matando a miles de estadounidenses es consecuencia del Flying Spaguetti Monster, mi nuevo Dios. Pero la verdad es que es una putada lo que ha pasado allí, especialmente sabiendo que estados unidos tiene los recursos para evitar "catastrofes" de ese tipo, en el sentido de evacuaciones y eso


Aun así no puedo evitar poner una foto del Flying Spaguetti Monster, creador del Universo

Flying Spaghetti Monster

30 de agosto de 2005

¿Donde terminarán los sistemas de archivos...?

Existe mucho ruido últimamente con la historia de winfs, spothlight, reiser 4, sus padres, sus madres, sus cuñados y las madres que los parieron. Y uno se pregunta: ¿A donde coño va a ir a parar todo esto?

La premisa de winfs (que aunque la gente se centra en la historia de las busquedas, es algo bastante más complejo que lo que pretende spothlight) es que "el usuario no debería preocuparse de donde están los archivos". Que todo debería ser una "busqueda, incluyendo la configuración de los archivos, etc. Aunque se anuncie como nuevo, resulta que el AS 400, un sistema operativo de IBM que no tiene "sistema de archivos", sino una base de datos enorme donde todo son peticiones. O eso dicen, porque yo no he visto uno en mi vida y la documentación al respecto no parece salir debajo de las piedras. El caso es que la idea no es nueva (para variar), y aparentemente pretenden reemplazar a los sistemas de archivos tradicionales

Ahora bien, sabemos porque unix tuvo en su diseño un sistema de archivos basado en archivos/directorios: Lo escogió porque era "simple y estúpido". Realmente, no hay nada más simple que un sistema de archivos basado en archivos y directorios, especialmente si lo comparas con la complejidad de una base de datos. Ahora bien, ¿tendrán éxito las alternativas basededatos-escas que están apareciendo hoy en día? Tal vez en los 70 los sistemas de archivos basados en bases de datos no tuvieran sentido, pero con la cantidad de miles de archivos que manejamos hoy, quien sabe. ¿Triunfarán las alternativas de bases de datos? ¿O prevalecerá la simplicidad de los sistemas de archivos tradicionales? ¿Sustituiran las bases de datos a los sistemas de archivos tradicionales como AS400, o simplemente se creará software database-esco que funcione por encima de sistemas de archivos tradicionales, como spothlight y parcialmente winfs? He de reconocer que me gustaría ser como Rappel y saber que ocurrirá en el futuro, pero....

A Rob Pike en su entrevista a slashdot le preguntaron exactamente eso, que qué opinaba de la moda de hacer a los sistemas de archivos UNIX más basededatos-escos, y la respuesta fue:

This is not the first time databases and file systems have collided, merged, argued, and split up, and it won't be the last. The specifics of whether you have a file system or a database is a rather dull semantic dispute, a contest to see who's got the best technology, rigged in a way that neither side wins. Well, as with most technologies, the solution depends on the problem; there is no single right answer.

What's really interesting is how you think about accessing your data. File systems and databases provide different ways of organizing data to help find structure and meaning in what you've stored, but they're not the only approaches possible. Moreover, the structure they provide is really for one purpose: to simplify accessing it. Once you realize it's the access, not the structure, that matters, the whole debate changes character.

One of the big insights in the last few years, through work by the internet search engines but also tools like Udi Manber's glimpse, is that data with no meaningful structure can still be very powerful if the tools to help you search the data are good. In fact, structure can be bad if the structure you have doesn't fit the problem you're trying to solve today, regardless of how well it fit the problem you were solving yesterday. So I don't much care any more how my data is stored; what matters is how to retrieve the relevant pieces when I need them.

Grep was the definitive Unix tool early on; now we have tools that could be characterized as `grep my machine' and `grep the Internet'. GMail, Google's mail product, takes that idea and applies it to mail: don't bother organizing your mail messages; just put them away for searching later. It's quite liberating if you can let go your old file-and-folder-oriented mentality. Expect more liberation as searching replaces structure as the way to handle data.

26 de agosto de 2005

debugging

Los posts en el planet de gnome sobre "como depurar sin símbolos" me han recordado a un magnífico post de Raymond Chen en el que explica una manera muy curiosa de identificar pérdidas de memoria

Ahora bien, leyendo el post de gnome me pregunto: ¿Es realmente necesario que las distros quiten la información de depuración de los binarios? Teniendo en cuenta que son los usuarios finales los que se encuentran con los fallos, y que son ellos los únicos que los pueden reportar, incluir la información de depuración de todos los binarios por defect no suena tan mal. El espacio de disco es barato. El de los CDs por supuesto no, y supongo que esa es la razón por la que muchas distros nunca harán algo así

Otra cosa curiosa es lo del bug-buddy: La cosa de gnome que cuando casca un programa te abre una ventana preguntandote si quieres enviar la información del fallo a los desarrolladores. Le hace a uno pensar si sería posible crear un bug-buddy que afectara a todos los programas de sistema (a todos los posibles) y que fuera configurable, para que las distros pudieran recibir automáticamente los fallos de todas las aplicaciones a través del sistema de seguimiento de bugs.

Por otra parte, cairo ha anunciado su versión 1.0.

24 de agosto de 2005

El fracaso de las aplicaciones web

Con todo el ruido de las aplicaciones web, AJAX, javascript & friends y todo eso, parece ser que nadie se atreve a decirlo, pero es evidente: Las aplicaciones web han fallado

¿Por qué? No hay mas que ver Google Talk: Es un programa normal y corriente: Al igual que google maps en la versión del programa, al igual que google/msn desktop, al igual que....

A día de hoy, tenemos cosas como gmail hechas a base de poner a los programadores a tirar de AJAX, pero para llegar a tener cosas como esas, se ha explotado al 100% las capacidades de javascript, xhtml, css & friends.

En resumen, las tecnologías de los navegadores de hoy permiten hacer "aplicaciones web", pero a base de explotar una tecnología que es una basura. Tanto javascript como CSS no son más que parches puestos a (X)HTML. Las web forms de firefox o el equivalente monopolista de Microsoft cambiarán las cosas, pero a día de hoy la verdad es que para aplicaciones web reales y competitivas, como uno no tire de java...

"Dep 1127 disbanded"

El "departamento 1127" era el departamento de los laboratorios Bell que se dedicó a crear y mantener Unix

Y ahora se ha ido para siempre. Tampoco es que sea muy relevante, despues de todo como dijo Rob Pike en el 91, "not only Unix is dead, it's starting to smell really bad"

Como curiosidad, 3 de los miembros están ahora en google. ¿Casualidad?

16 de agosto de 2005

certificación de drivers en Windows - el HORROR

En la última entrega de "The Old New Thing" (blog de uno de los mejores ingenieros de Microsoft, etc etc), explica uno de los métodos más curiosos que utilizan las empresas para saltarse el diálogo de "Está a punto de instalar un driver no certificado por los laboratorios de Microsoft etc etc":

El método que cuenta esta vez (hay más) es escalofriante: El programa de instalación pide al usuario que "no mueva el ratón ni toque el teclado". Entonces, el propio programa de instalación procede a mover el puntero del ratón manualmente, para actualizar el driver y aceptar el diálogo como si fuera el usuario el que lo está haciendo

Terrorifico.

Y relacionado con el tema, y sacado de la keynote del todopoderoso John Carmak: "The quintessential PC game programmer then dropped a bit of a bombshell by announcing that he had recently moved his primary development efforts over to the Xbox 360, and that he expected to continue development there for the next six months—although the PC version of id Software's next game will still be released first. One of his reasons for the move to Xbox 360 for development, Carmack said, was the headache of driver issues on the PC platform. The several layers of abstraction on the PC make it hard to nail down exact graphics performance because the programmer is held at a distance from the hardware. By contrast, the Xbox 360's more direct approach was "refreshing." Carmack also praised Microsoft's development environment as easily the best of any of the consoles, thanks to the company's background as a software provider"

Y ya que estamos: "Carmack was less pleased with the PowerPC processors for the new consoles, questioning the choice of an in-order CPU architecture. He estimated the console CPUs' performance at about 50% that of a modern x86 processor and expressed skepticism about the returns of multi-core designs and multithreaded software, especially in the short term. Graphics accelerators are a great example of parallelism working well, he noted, but game code is not similarly parallelizable.

11 de agosto de 2005

"La razón real por la que IE7 no soportará CSS2"

En http://dean.edwards.name/weblog/2005/03/the-reason han escrito un par de lineas decentes en las queda una razón bastante lógica para que IE7 no vaya a soportar CSS 2 (y ni hablar de CSS 3): Por que no pueden

Las razones que da son bastante coherentes: Internet Explorer es un navegador que no ha sido modificado en 3 años (excepto cambios en el SP2 de XP, en materia de seguridad especialmente en el tema de zonas, en cualquier caso nada relacinado con CSS & friends), y el motor de renderizado está completamente obsoleto como para implementar cosas "avanzadas" con facilidad.

Lo cierto es que en los blogs de los desarrolladores de mozilla hablan sobre como la futura migración a cairo les permitirá implementar tal o cual característica de forma mas sencilla. O en otras palabras: Uno no va e implementa CSS como si tal cosa, el diseño del navegador te lo pone más o menos dificil.

Asi que lo mas probable es que el tipo ese tenga razon y que el motor de renderizado de IE7 sea a día de hoy "viejo", y que implementar CSS 2 & 3 no sea cuestión de gustos, sino de complejidad y falta de tiempo: Firefox está ahí, y necesitan sacar algo que compita con ellos. Tal vez si se les diera tiempo podrían implementar más cosas, pero es obvio que no van a retrasar la salida del IE7 por esas razones. Tambien dice que IE es el nuevo netscape 4.7, y que para IE tiene mas sentido una reescritura que continuar parcheando

"algoritmos de reemplazo"

Rik van Riel, el tipo que hizo el famoso "-rmap", está atacando de nuevo

9 de agosto de 2005

OO y el futuro de la programación

Acabo de encontrar en mis bookmarks un enlace que consideraba perdido, pero que afortunadamente no lo esta: Una entrevista con Victoria Livschitz, una tipa que trabaja para sun y que es campeona de ajedrez de su pais. La entrevista va sobre la programación, sobre nuestra incapacidad para crear grandes programas que no esten plagados de fallos, de como la orientación al objeto ayudó a mejorar las cosas, de como no ha ayudado a arreglar todos los problemas, y todo eso:

[...] However, we seem to have reached the point where OO is no longer effective. No one can comfortably negotiate a system with thousands of classes. So, unfortunately, object-oriented programming has a fundamental flaw, ironically related to its main strength.

In object-oriented systems, "object" is the one and only basic abstraction. The universe always gets reduced to a set of pre-defined object classes, some of which are structural supersets of others. The simplicity of this model is both its blessing and its curse. Einstein once noted that an explanation should be as simple as possible, but no simpler. This is a remarkably subtle point that is often overlooked. Explaining the world through a collection of objects is just too simple! The world is richer than what can be expressed with object-oriented syntax.

6 de agosto de 2005

vista tendrá enlaces simbólicos

Parece que Microsoft sigue con su plan de alcanzar el nivel de la tecnología de los 70. Lo cual por cierto no es malo, y nos hace ponernos a su misma altura si no avanzamos y nos quedamos atrancados en la misma historia. Curiosamente, Plan 9 no tiene enlaces simbólicos (a propósito, como consecuencia de sus rollitos-de-espacios-de-nombres)

28 de julio de 2005

Linux kernel developers' Summit

Bueno, ha terminado hace unos dias, pero por fin lwn.net lo ha liberado (liberaran sus maravillosos artículos al cabo de una semana)

Y aquí está

Y los PDFs de todos los ponentes tambien están, unos pocos cientos de páginas: uno y dos. Plagados de temas interesantes, como por ejemplo futuras extensiones del ext3, la siempre presente charla sobre la gestión de memoria, como acelerar la carga de programas (traducción: Como ponernos al día con respecto a XP), NTPL, rendimiento del caché de páginas, y cosas interesantes

Ah, y la beta de IE7. Si ayer se sacaban a la luz las maravillas del IIS, hoy toca el IE7: Para activar/desactivar las pestañas del IE7, hay que reiniciar el sistema. Surrealista.

14 de julio de 2005

Raymond Chen rocks

Uno de los más brillantes ingenieros de Microsoft ha escrito unas cosas contando como la gente de Marketing de Microsoft a veces le editan las diapositivas de las charlas que va a dar, y en la última le han hecho algunos cambios, entre ellos poner su nombre en el resumen de la charla.

Y parece que no le gusta, porque, según dice, las charlas están para hablar de algo, no de alguien, y que él está ahí para dar una charla sobre algo, no sobre si mismo. Y que por esa misma razón no concede entrevistas, porque las entrevistas tratan sobre alguien y que la gente debería preocuparse de la tecnología. "If I were just there to be me, the title would be "Raymond Chen reads the newspaper for an hour while listening to music on his headphones", dice el muy cabrón