During this week-end I tried to give initial impulses on several projects of interest for me : DebianEduFrench: a new mailing list has just been setup for this project. We intend to foster cooperation between several French educational Debian-based projects. We’ll try to integrate their work into Debian directly to avoid needless duplication of effort. This follows my last call for help on debian-devel-announce. If you speak French and have good packaging skills, you’re welcome to join and help us on the mailing list. Collaborative maintenance infrastructure: this one started as a project to handle orphaned packages but after the talk we gave at the Debian-QA meeting in Darmstadt, we agreed that it is of broader interest: in particular for mentoring future Debian developers. This tool could also interest Ubuntu which has in fact already started something covering a part of this proposal: REVU (development web site). So I crosspossted a call in several Debian & Ubuntu lists in order to create a little team to work on this project and make it happen. But there’s still room for discussions as nothing is in stone yet … That’s enough for one week-end !

To Wouter: No, I never used anything else than CVS for everything serious. Whenever I tried any of them for something (mostly because someone else used it for something I wanted to work on) they simply broke. I don't want debug my tools or use funny workarounds but get some work done on what I use the tools for. Using anything not in a Debian stable release is hardly acceptable for me (remember, it are tools), but when then even when the testing or unstable versions are not enough for simple tasks, it's just too bleeding edge for me.

"only suggests you haven't seen many large projects in the heat of code change"

That's simply a matter of style. If a checkin means a full compile, manually reading the diff and a minimal checking for correctness, writing Changelog entries and possibly adopting the documentation there is simply no need to handle checkins with a sub-minute resulution.

"Far too often have I seen people afraid to reorganize their code because that would lose history on the files."

That's a major problem, but the problem is the fear. No rcs will ever be able to track history for even most common possible reorganisations of code. Limiting yourself to what your rcs can cope with is the main problem, the abilities of your rcs are a minor one.

"How about the fact that upstream CVS development is rather extremely dead, [...]"

I prefer tools being able to do what I need over tools that will be able to adopt my needs normaly. Active development means when I encounter a bug I either have to wait a year until it does no longer bother me, or wait a week and update software on every computer I want to use on, possibly localy in my user account if I do no administrate the computer or the behaviour changes so much other usages are broken. Leading to problems to live within my disk quota and so on.

Don't understand me wrong, I'm not against SVN. I guess now (several years after everyone was already told to not use that old fashioned CVS, but not SVN version N but version N+1, because N was too brokenr; for several versions of N) it is quite useable. And things like atomic commits might even make it favoruable over CVS for larger projects. But not every project can be within the top ten list of size, coding and commit styles differ. But I believe for many people, the ratio of advantages to disadvantages still points into another direction.

Well, it's certainly the most amusing spam I've seen in a while. Sent to debian-security@l.d.o:

"Please pardon the intrusion. You are receiving this invitation because at one time or another, you expressed an interest in music on the internet. Since then, we paid someone for your email address. It's that simple."

Or was it generated by a computer picking random buzzwords? Take a guess.

The semantic mark-up languages would be used to specify the convergence of business and IT models, and more importantly, their metamodels. The ontological representation of the metamodel of a constituent model enables reasoning about the instance model, which enables a dependency analysis to deduce unknown or implied relationships among entities within the instance model. The analysis would be extended across multiple layers of models. The semantic model-based dependency analysis would reveal which entity has an impact on which entities (for example, business components and processes, performance indicators, IT systems, software classes and objects, among others) of the model. This semantic model-based analysis would be applied to a model that provides an introspective view of the business within an enterprise. Also, it would be applied to a value network that yields an extrospective view of businesses in an ecosystem.

As many people have expressed in their blogs after Bubulle's initial rant, I am also joining the game :)
Some weeks ago I decided to finally move my personal documents repository from CVS to SVN - Why SVN? Because I don't need a distributed system, I am the only person with write (or read) access to it... Besides, I'm too lazy - The one feature that made me start using SVN and not any other system is that you can use it just as if it were CVS, but without the ridiculous constraint placed by just integrating many individual files instead of managing the whole beast as a repository.
I had a problem, though, that made me lose good part of an evening - I think it might be related to #333105, but I'm not sure: I converted my repository using cvs2svn, which saved all my five years worth of commit history (whee!), grouping commits that seemed to belong together in single SVN transactions (whee!!)... But binary files were all corrupted. To make things worse, I didn't notice this until I had to present a talk in Peru - and my laptop's working copy was severely FUBAR.
Well... I managed to give my talk - And yesterday I finally decided to restore sanity to my life, reviving my doc_gwolf SVN tree. The stupid steps?

• cvs2svn --encoding=ISO-8859-1 -s /home/cvs/doc_gwolf /home/svn/doc_gwolf
• cd /tmp; svn co file:///home/svn/doc_gwolf
• Locate all files which differ between the two checkouts
• As I had done some work without committing, check against the list what was text, what was binary
• For each of the binary files, svn remove $file;cp /tmp/cvs/doc_gwolf/$file $file; svn add $file
• Add/replace all the files which were locally modified
• Everything seems to work? Ok, svn ci, and be merry.

Phew :-/

I never thought anyone would still seriously advocate CVS over anything else these days, but I was wrong. Bernhard:

• Ever heard of atomic commits? You modify three files, commit. Turns out that in the time between you starting to edit stuff and you committing, someone else changed some stuff, and your commit doesn't apply somehow. The first file is committed, the second breaks, and the third isn't committed. Congratulations, you just broke the build, and you'll have to manually fix it. When editing three files, that's manageable; when your commit is (say) about 15 files or so, it's not really as manageable anymore. CVS doesn't have atomic commits.
• About it being rock solid, I only say Hah. I've seen way too many cvs pserver bugs out there—and that's still the only possible way to go if you want anonymous CVS access.
• How about the fact that upstream CVS development is rather extremely dead, after most of their developers started to develop subversion because the CVS code is so extremely horrible to maintain?
• Moving files around isn't just a nice thing to have; it's an extremely important feature. Far too often have I seen people afraid to reorganize their code because that would lose history on the files. If you can't move files, you can hardly ever reorganize code, which means that you let your version control system dictate how you should work—which is bad, very bad.
• And finally, being able to tell someone that this is fixed in r132 rather than having to say this is fixed in r1.74 of foo/bar, r1.34 of foo/baz, and r1.82 of foo/quux is very helpful. Your suggestion about dates (there's normally at least a quarter of an hour between commits) only suggests that you haven't seen many large projects in the heat of code changes. And even if that weren't true, the fact that it normally isn't a problem makes it even more of a problem on the occasions that it, in fact, does take less than a few seconds between my commit and yours

Really. Have you tried comparing CVS to anything else, on a serious project? There should really be a way for all those version control systems to talk to eachother. After all, they all have one thing in common: they're all ways to exchange patches. Surely there must be some way to device a protocol or something so that those patches can be easily sent from one version control system to the other and back again?

h01ger thought that maybe I should clarify a few points in my blog. Well sure, I can do that. First of all, I think Joey does great security work. I am not attacking him for this. Second, I think Joey does a great job with Debian in general. However, I think he’s seriously harming Debian by not opening up and organizing the security infrastructure, and this is where my problem lies. I hope I’m getting this point across. There have been a number of attempts to revise the infrastructure and organization; a meeting in Oldenburg, where the testing-security crew attempted to get Joey to use their work; proposal(s?) by the DPL; AJ is now working on security queue stuff. I really do hope that Joey decides to work w/ AJ (or any of the other people who’ve suggested different ways to handle Debian security), for the sake of Debian. Joey keeps looking for additional manpower, and gets frustrated when people don’t contribute. Well, as someone who has attempted to contribute, and has seen others attempt to contribute, we get frustrated when our contributions are ignored (in the case of the kernel security update, the i386 and source packages apparently sat around for 4 months). Maybe if all this happened in the open, instead of amongst private emails (that often times go unanswered because Joey is busy), people might not get discouraged, and will continue contributing. I personally don’t think anything has been solved, and unless Joey is actively working w/ Branden or AJ in private, I don’t see any progress towards solving a problem that will require openness, organization, and trust. Manpower can follow after that.

I wrote an article, here: http://www.dedasys.com/articles/webhosting_market_lemons.html about why I think the market for web hosting is a "market for lemons" - the fact that you can't really tell ahead of time what the quality of service will be like causes it to be a problematic market in some ways, both for service providers and consumers. It's a work in progress, so ideas, comments and suggestions are welcome!

Given that the perennial, uh, “discussion” about GNOME’s features is on us again, I thought I’d share the method I use to remove options from Quod Libet. I break them, and see how long it takes people to notice. Well, no, not really, but the amount of brokenness in an option is a good metric for whether or not people change it. One of the first options in QL was a checkbox for “Show album cover”. Sometime around 0.7 or it became impossible to turn this off, and I didn’t notice until I was redoing the preferences dialog for 0.11. Rather than fixing it, I just removed a few dozen lines of code and made it always on. No one has ever asked for it back (though someone probably will now). This has happened a couple of times. On a related note, three months ago Bram Cohen made an interesting post about configuration in software, which has been rolling around in my head picking up smaller objects since. There’s a lot of “configuration” that we don’t think of as configuration — for example, the volume in an audio player is stored in basically the same place (same file, GConf tree, whatever) as, say, where the program looks for files. But we only think of the later as part of our “configuration.” That’s because we control the volume “nearby,” in the same place we view it, but the location to look for files in a very different spatial place (an entirely separate window). No one would be crazy enough to put a volume control in a Preferences dialog. So “configuration” becomes synonymous with “hard to find”. The answer to configuration creep, then, is to provide as much direct manipulation as possible. At least from the UI perspective. You’re still screwed from the combinatorial explosion on the implementation side. Beyond that, one thing I’d really like is for context menus to be more common. That is, users should be able to expect to right-click on a widget, and change changable aspects of that widget. This also means making right-click involve no surprises — it shouldn’t activate buttons, shouldn’t delete things, etc. Otherwise people will be too afraid to right-click to try configuring. This feels like a good substitute for when direct manipulation isn’t really possible, because the most direct form of manipulation is already taken up by the widget’s primary purpose. Anyway, Quod Libet is going to be moving in this direction in the future. We already have plugins configurable in the same dialog where you turn them on and off. In 0.16 the tray icon has become an interface almost unto itself, and so it has a separate Preferences dialog now, launchable only from the icon. (It also only has one thing to configure, but that might change. Most importantly, it can grow, without getting in the way of people who don’t care about the tray icon.) For 0.17 I’m probably going to fulfill the common “display remaining time” feature request by putting a radio context menu on the time display. And so on. Fixing Real Bugs
But enough about UI wankery. Does anyone know of a nice C parser for Python? Inspired by a bug he found in mmapmodule, Michael’s written a tool to find type signature issues in CPython functions, but its usefulness is lessened by the fact it returns a ton of false positives and probably also misses many things as well. You Are All Self-Absorbed
My project for a class this semester involved trying to extract useful categories from the link structure of weblogs. Unfortunately it turns out weblogs are all about navel-gazing, and the link structure isn’t at all useful. The majority of shared links on Planet Perl,Debian,GNOME,Python pointed to perl,debian,gnome,python .org, and the majority on MSDN Blogs pointed to microsoft.com. Only about 10% of links pointed to a post on another weblog. Given that additionally weblogs tend to not have comments (and even if they do, people reply in another weblog post anyway), that’s kind of sickening. Can you imagine how much email would suck if only one out of every 10 mails got a reply? I wouldn’t be able to spend all day reading about how Debian’s FTP masters are doing their job properly.

A shiny new release of Quantian is now available! Release 0.7.9.1, available as a iso file of 2.5 gb, contains almost 7 gb of quantitative, numerical or scientific software. This release is the first one based on Knoppix 4.0.2 and features:

• Kernel 2.6.12, KDE 3.4, OpenOffice 2.0, ... and more from Knoppix 4.0.2
• a backport of the openMosix-enabled 2.4.27 kernel and openMosix tools from the last clusterKnoppix release,
• very comprehensive support for GNU R with over 800 packages from CRAN and BioConductor, plus ESS, Ggobi, Rpad, RKward, ...
• newly added packages such as scigraphica, polyxmass, gromacs and more
• content from metapackages from Debian Med, Debian Edu and Debian Junior
• and still loads more of math, bio, engineering, LaTeX, ... software

Downloads are available from the Quantian site at the Fred Hutchinson Cancer Research Center in Seattle and at from Greg Warnes' machine at Yale. European mirrors should be in sync within a day or two, Bittorrent support via the Linux Mirror Project should also be available soon. Note that http transfers seem to be problematic due to the file size of over 2gb; rsync and bittorrent are probably a better approach. More information is as always available at the Quantian pages.

It's been an interesting 24 hours. Monday
8:00 PM
I get home after working a regular day and having supper with a friend. 8:15 PM
One of our friend from church -- who happens to live a few blocks from my workplace -- calls. "Did you know your workplace is on fire?" "Uhh, no...." "Yeah, big fire, flames, dozens of emergency vehicles..." "Hmm..." So then I call my manager... "Did you know the company is on fire?" "Uhh... no...." "Yeah, sounds bad, I'm going to head in and see what's going on." 8:30 PM
I arrive at work. Cops have blocked all the entrances. I identify myself as an I.S. manager and am directed to the "manager area". (Others are kept across the street.) An eerie orange glow -- and lots of smoke -- is visible above the rooftop. This looks bad. We learn that something in the compressor room caught fire or exploded. Fire spread upward quickly. Most importantly, everyone got out without any injuries. 8:35 PM
Our T1 provider calls my cellphone. These are really, really good folks. I answer, as I'm standing next to a noisy fire truck. ISP: Hi. Just calling to let you know that your T1 is down and we're looking into it. Me: Hmm. That might be because it's on fire. ISP: Uhm, did you just say it's on fire? Me: Could be. There's a fire in the building and we're not allowed in just yet. Plus the electric company is trying to cut the power. ISP: OK then, I think we're going to assume the problem is at your end for now. This sounds bad. I know the I.S. dept. still has UPS power, since the phone system attendant is answering. But if the T1 is down, it seems that it must have burned up (its run goes very close to the affected area), and taken some phone lines with it. 9 PM
It's below freezing already, and I didn't bundle up very well. Several waiting -- but unused -- ambulances are nearby and the paramedics invite those of us waiting inside the heated vehicles. 9:30 PM
The CEO and CFO are permitted to tour the building with a firefighter. Word is that sprinklers have come on and there's water in the I.S. dept. This is potentially really bad news. The I.S. dept is in the basement and water has been a problem before, so we're prepared, but water and computers are never a good combination... After a little while, we are allowed inside as well. There is 1 to 2 inches of water on the floor in the basement, but fortunately nothing has reached the raised floor yet. The fire department supplies an AC generator to power the sump pump, plus 6 squeeges. We supply 6 people. We keep on the squeege duty until about midnight. Meanwhile, it turns out that a water pipe broke out in the shop near the fire. Water gets shut off. But the floor up there appears to unfortunately slope towards the staircase that leads to the basement. Water is coming down fast. We find what we can to block the path, and that seemed to just make the collection deeper. I periodically try to find someone that can bring a pump and a generator -- or something -- to help this get cleared up. Midnight
I head home. The water situation is improving, but not resolved yet. Others remain. Once home, I post a notice on our public website saying that our power, Internet, phone, and FAX lines are down. You just might have a problem reaching us. I also e-mail some consultants, saying that the reason the VPN doesn't work is that we had a fire. I also e-mail the new I.S. person who has an hour commute and advise him of the situation. Our fire was top story on one of the local newscasts. We watch the video of it, sigh at the annoying "on the scene" reporter (motto: "things were interesting an hour ago"), and turn in. 1AM
Time to sleep. Tuesday
6AM
Get up, in to work by 6:45. Everything is dead. No power, no water, no phones, no heat, no gas. Also, fortunately, no more water coming down. I call the other I.S. developer and tell him not to bother coming in right now, but maybe we'll call later. 8:30 AM
An impromptu meeting happens. The CEO sets communications as the #1 priority: phone and basic Internet access. Plants 2 and 4 have working power, so if we can bring up some servers and network gear on a generator, computers over there will work. No water in plant 1, where my office is. So nearest restrooms are a 5-10 minute walk through dark and damp areas. Bottled water, coffee, and donuts appear at the halfway mark to the restrooms ;-) 9:00 AM
Generators start appearing near the I.S. dept. After getting them powered up, proper extension cords found, etc., we start plugging in the phone system. Power strip 1 works. I flick the switch on power strip 2, and it all goes dead. This generator's circuit breaker keeps doing that every time we try to turn on the phone system. So we try generator #2. Phone system finally powers up. But all incoming lines are ringing at phones in sales. Volunteers go up to answer those phones. Meanwhile, phone tech shows up, and orders his own, larger generator. I call our person that's an hour away and tell him to go ahead and head in. 10:00 AM
Now we turn to the computers. We're going to have to be careful what we bring up so we don't overload the generator (and thus have an unclean shutdown on anything that's already up.) I recable power to some switches, our T1 router (ISP calls: the T1 just came up! yay!), and our firewall. Flick the switch on firewall. Generator stays up. Firewall emits a high-pitched whine. Eeep. Flick the switch again! After checking things out, we adjust the voltage a bit and determine that things are generally OK. I run the firewall on one of its two power supplies. At least if it burns one out, we can still run it off the other later. Turn it back on -- whines again, but it goes away after a few minutes. Phew. Next step: our main Linux file server. Flick the switch, and there's a satisfying "whoosh" from the fans. Excellent. Our developer shows up and observes later: "John, this was odd. When I got here, there were 7 guys standing around watching you boot up machines." 11:00 AM
Decision time. Our main ERP server is an AIX box. 8U. About a dozen disks. Certain to be a large draw. Can the generator handle it? Yes, it should. Should we power it up, given that it takes 45 minutes to come up and 20 to go down? We opt to try. I cable it up and press the power button. Nothing happens. But that is normal for AIX. After a few minutes, we start seeing hex codes on the LCD. A few minutes later, disks start coming up. All looks good... 11:15 AM
Orange alert lamp comes on for the AIX box. Uhoh. Turns out one of the drives in the RAID is bad. Time to call IBM, but at least it's mirrored to the box is up. IBM service calls are always "fun" for this. I spent a total of about an hour on the phone with them, 90% of which was spent with them analyzing error logs trying to find out what exact part number to give is, and 10% spent trying to look up our account information. Plus, the phone guy is now switching the phone system to his genset. He tries to hook it up through a home-type UPS, which is giving him fits. I get disconnected from IBM at least twice. Noon
My supervisor goes to Subway and brings in lunch for all four of us in I.S. since we don't really feel like we can leave. Word arrives that the generator that's powering the servers is leaking oil. Eeep. But it should be good until evening. On the plus side, the generator will automatically shut itself off when it runs out of oil. Won't damage itself. 1PM
IBM calls, trying again to get information about what exact part they need to bring out. Only 29 minutes on the phone this time. Word arrives that a 60kW generator has arrived that they will attempt to hook into the mains supply for the building. The main power distribution center has been burnt. Plus we aren't allowed to touch large parts of it since fire inspectors and insurance adjustors aren't done yet. But no ETA on the big generator. We make a preliminary decision to cut power to computers & the network at 5PM, and maintain the single phone system generator overnight. 2PM
Local IBM rep calls. He'll be out between 3:30 and 4. I say that'll be fine, but warn him that if he's any later, the power may be down. 3:45PM
IBM rep shows up, replaces the dead disk. It works. Whee. 4:15PM
I start powering down the AIX box. We then learn that ETA on the big generator is 5PM. So we start shutting down other servers as planned. 5PM
Big generator comes up. It works. We slowly bring up our systems. Everything is good. BUT -- we are basically maxing out the capacity on the generator. People will not be able to just come in and work like usual tomorrow. We'll be meeting in the morning to figure it all out. 6PM
We post signs at entrances warning people to not turn *anything* on. Finally head home at 6:30.

With this rcs debate currently on planet.debian.org I feeled the need to add some toughts.

My point is mainly: Why not simply stick to plain old CVS?

The pros are easily collected: it's installed everywhere, almost everyone know at least the basic commands, and it is rock solid technology without all those little nasty bugs the newer ones have all the time.

Most of the contra arguments are not applicaple to me, so how can they to anybody else? ;-)

Like changelog messages: I write a Changelog after a patch, because I look at the patch for doing so. After all, that is what the Changelog is supposed to document, not what I though I did. (And looking at this is always a good way to catch some obvious mistakes one did).

Making multiple patched off other people's projects: Two versions of the directories you are working on is all that is needed. Change the one, make diffs compared to the other. Revert the diff (patch -R or just answer often enough), change the diff to what it should be, reapply it to make sure it still works, test it, revert it again. To make another patch for the same original software, continue from the begining, otherwise apply the patch to both copies. Just works. Easier than any darcs or co, even if that would not core dump, go into endless loops or play dead dog.

Even the non-exotic new systems still have plenty of features I never needed:

Something has to be really big moving files around is needed at all. And if it is needed, just delete it here and add it there. That looses a bit of history, but that is still found in the older place's history. Moving whole files is there only a special case of moving routines between files while refactorisation, one sometimes just has to look somewhere else.

Even for svn's global revision numbers I have not yet found a use. Being used to cvsish tagging removes the need if thinking before, and between commits there is normaly at least a quarter of an hour, so date based indexing always works.

So, what are we talking about?

I just love this place. While the 8 o'clock news said that the parliament would be debating tuition fees today in their shiny new meeting hall that was built for 9.9 million Euros and features leather seats and Internet connection at every seat, the 9 o'clock news said they were discussing countermeasures against trucks evading the Autobahn tolls. While the first report was obviously biased against tuition fees, I think that it's somehow scary that the report was replaced in its entirety while the remaining pieces were word by word repeated. Well, another reason to leave this place as soon as

Oops. Engadget reports that Play-Doh fingers can fool 90% of all fingerprint scanners. This is nothing really new. The remarkable thing is that more and more companies and government organizations rely on such biometric authentication. Now, they all have been told about the problems, but nobody seems to want to listen... (via Techdirt)

The past few days I have been accumulating knowledge. I have encountered quite some new concepts and stuff they use here, but also old knowledge had to be refreshed. I have looked again at XML technologies as W3c XML Schema, RelaxNG, XSLT and XML in general. I had to dive into OCaml since that’s the main language used here. Fortunately I can make use of my past Haskell experience there. So now I have yet a new language to add to my used-programming-languages list. I have used my webspace provided by MACS to set up a page about all my internship work related stuff. It gave me another opportunity to make use of webgen again, what a great tool! Simple text files in a directory structure are converted to a site with such ease. A title, menu and navigation bar, all done automatically and it’s all static HTML in a nice XHTML 1.1 compliant package. MathLang I have read all the available presentations and papers on MathLang that I could find. At the TU/e I was taught the Weak-Type Theory by professor Nederpelt (which is a basis for this mathematical language), so I have some background in this area. I’ve tried to write a page about what MathLang is. I’ll probably have to improve the descriptions and make the whole thing clearer. The Plan My first task will be to write a MathLang-Core concrete syntax compiler that can generate the still to be defined XML format. The AST used in this compiling process should also be prepared so that the MathLang type checker can run on it. Once the compiling to XML is done, I might be able to use XSLT to transform it back to the original syntax, hence proving the equivalence of the two syntaxes. For monitoring my progress, see my online log.

There have been a lot of hype lately about Social Network or Web 2.0. Of course this is not anything new, but a translation of natural social relationships to the network. Haven't you ever showed your travel photos to your friends or family? Well, in an exercise of exhibitionism you can now show them to the World using a tool like Flickr. Yeah, you could show them before using your blog, which it is also a way of Social Network, but now you can see not only your friend's and family's photos, but a set of them made by people from all around the globe. At the same time, you can still publish your thoughts in your blog, and read other people's thoughts in these different Planets or using an RSS aggregator. Was blogging what started all this? Well, talking with a friend of mine the other day we realized that the impulse of publishing in people is amazing. Before blogs started to exist everyone wanted to have his own personal webpage in Internet. And the revolution was GeoCities. With it anybody could publish his homemade webpage... which usually was a webpage talking about a hobby, or the family, with different links, but few live content. People want to share... want to share experiences, photos, ideas, bookmarks, ... want to talk with friends and family, wherever they are, and this is why IM now (and VoIP in a near future) have had so great success. First half of the 21th century is going to be voyeurs epoch!

I just received my first Tribe.net “internal” Nigerian-type scam email:

There’s a new message in your Tribe.net inbox from jenny
Message details: hello Adam
Dear Adam, Please i decided to write you because i have no other alternative. Since after the death of my father in the hands of the rebels i have been in a very big difficulty of how to safeguard the money that my father left for me before his death because,the money is too much that i am afraid i dont know how and where to start to go about it. Please if you can help me try to reply me urgently and i will tell you how much and explain more to you and we can discuss fully and God will always bless you for your help whch i know you shall never regret as i am going to take you as my father. I am Waiting eagerly to hear from you.you can write me through jen_221n@yahoo.com Sincerely Jennifer.

I suppose it was only a matter of time. I wonder if Friendster and other similar FOAF services are prepared to deal with the infiltration of their networks by scammers and spammers.

It's a month since I was exposed to excessively loud music at a concert and the tinnitus is getting worse. Imagine an infinitely long blackboard, and someone walking along, squeaking the chalk, forever. The sound is in your head when you go to bed, there when it wakes you up at night, and there at every moment of the day, demanding your attention. Damage to the inner ear does not heal. There is no cure. You are told to learn to live with the incessant noise, and to look forward to a life without silence.