I received this today :
From: tezz hurtReply to: tezz_teco@yahoo.com Subject: i must kill you Date: Sat, 6 Oct 2007 16:09:00 +0000 (18:09 CEST)
I am clifford avrus the murderer who lives in united kingdom. but i was paid 100.000.000 to eliminate you,but i decided to let you know where exactly your death is coming from.
Did you ever offend your friend who planned now as i am mailing you to kill you.Anytime from now i will be at your family home first to kill number of your family,and thereafter you and so close to you.
All your contacts and families contacts are with me now,i just felt that i should let you know before coming after you.
E-mail to contact me:tezz_teco@yahoo.com
Google does not know this message, and that's the first time I see it. It was sent from an IP in Nigeria...
What do they expect with such message ? Just getting a reply ? Did any of you get this too ?
The JDLL are over, and were once again an opportunity to spend time with cool and interesting people. Due to a strike I could not go there by train on Thursday evening as planned, but we rented a car on Friday so I only missed the first day.
I only attended 2 conferences (libcaca by Jylam and DRM by Sam) and spent most of the time on GNOME booth or talking on other booths.
On Friday evening we had a Slashdot birthday party. Aurélie had organized the release of the so long awaited Duke Nukem Forever, and we now have this DVD box that I could maybe sell on eBay :)
On the way back to Paris I have also learned that driving a car is more difficult than driving Debian.
Here are the result of starting the interpreters in valgrind with an empty script : perl, php, python, ruby.
So, Ruby is OK, Perl and PHP have small memory leaks, but Python has a bunch of worrying errors including undefined behaviors and uses after free !
Of course this does not imply anything on how they manage their memory later, but I think that being clean in the simple case shows if you care about it.
Update: A Rafael wrote in the comments, Perl does not free its objects by default when the interpreter is destroyed, and even if I can't test it, running PERL_DESTRUCT_LEVEL=2 valgrind perl -e '' should not show any memory leak (if your perl was built with -DDEBUGGING). As he pointed out, perl even has a Makefile rule to run all the tests under valgrind.
Update 2: as several people pointed out, the "Use of uninitialised value" from Python are expected and harmless. Does someone have an explanation for the read after free ? :)
Pascal [I have read the text twice and I fail to understand why they are "not a problem". From what I understand, he says that..]
haypo [ou should read this document about how to use Valgrind with CPython: http://svn.python.org/projects/python/trunk/Misc/..]
Pascal [Someone smarter than me explained me README.valgrind and indeed this should be OK :)]
It is now public so I guess I have to announce it :)
I will still work for Mandriva but starting next Monday I will move to the kernel team after 3 years working for professional customers. This is a great opportunity to improve my skills in this area, I hope I will be up to the task!
After reading this last week, I had a look at the hardrive of my IBM T40 (the hardrive is only less than one year old, the previous one had died).
smartctl -A /dev/hda | sed -n 's/.*Load_Cycle_Count.* //p' told me it had experienced 540 205 load cycles within the 7037 hours it had been up. With the article talking about 600 000 lod cycles I got quite worried, and indeed I often ear clicks when I don't use the disk.
So, I changed /etc/sysconfig/harddisks to set EXTRA_PARAMS to -B 255 but that did not help : it is only run at startup and it looks like it gets changed again afterwards. I then put a cron job to set it every 10 minutes, and still got about 6000 Load Cycles in less than one day. So I changed the cron to run every minute, and I only got 11 new Load Cycle since (in 4 days !). I think they still occur at boot time, before linux has even started booting, as I could ear some while looking at options in the BIOS.
So, my solution is * * * * * hdparm -B 255 /dev/hda >/dev/null 2>&1
This is really ugly so I have to find a way to avoid the BIOS setting back this bad value.
Before...
Pascal [Misc: tu sous-traite maintenant ? On manque de main d'oeuvre ?]
Lea [I also got the same email today with just slightly different words and from different addresses.]
malakhi [Hey, I got that message, too. I actually posted about it on my blog: http://malakhi.net/blog/2007/10/death-threats-an..]