Due to a variety of people and places we want to see, Mika and I have regrouped around a more ambitious travel schedule in Italy for the next week or so. Our new plan is:

• August 23-27: Florence
• August 27-29: Verona
• August 29-31: Bologna
• August 31-September 1: Siena
• September 1-3: Rome

I know we'll have an organized LUG meeting in Siena. The rest of the period is a little more open. As always, if other free software, wikimedian, or like-minded folks are around and would like to meet up in any of those places, don't hesitate to get in contact. In related news, inspired by Florence and by Mika's domo-kun purse, I made a duomo-kun today.

The Chicago Symphony hosted the world premiere of Louis last evening, and I had snatched the (literally) last available ticket. The film, which is written, directed and producted by Dan Pritzker, is based loosely on the early years of Louis Armstrong in New Orleans. The movie is shot beautifully by Vilmos Zsigmond in blend of colour and black-and-white which works very well for invoking the early days of film. A key part of the production is of course the score, and the live music with both a thirteen-piece orchestra featuring Wynton Marsalis as well as piano solo recitals by Cecile Licad with an emphasis on pieces by 19th-century composer Louis Moreau Gottschalk. The combination of a silent movie with a stong live band is something to behold -- if you can catch the movie and performance in a city nearby, go!

My file system sematics program presented a few days ago is very useful to verify that a file system can work as a unix home directory,and today I had to extend it a bit. I'm looking into alternatives for home directory access here at the University of Oslo, and one of the options is sshfs. My friend Finn-Arne mentioned a while back that they had used sshfs with Debian Edu, but stopped because of problems. I asked today what the problems where, and he mentioned that sshfs failed to handle umask properly. Trying to detect the problem I wrote this addition to my fs testing script:

mode_t touch_get_mode(const char *name, mode_t mode)  
  mode_t retval = 0;
  int fd = open(name, O_RDWR O_CREAT O_LARGEFILE, mode);
  if (-1 != fd)  
    unlink(name);
    struct stat statbuf;
    if (-1 != fstat(fd, &statbuf))  
      retval = statbuf.st_mode & 0x1ff;
     
    close(fd);
   
  return retval;
 
/* Try to detect problem discovered using sshfs */
int test_umask(void)  
  printf("info: testing umask effect on file creation\n");
  mode_t orig_umask = umask(000);
  mode_t newmode;
  if (0666 != (newmode = touch_get_mode("foobar", 0666)))  
    printf("  error: Wrong file mode %o when creating using mode 666 and umask 000\n",
           newmode);
   
  umask(007);
  if (0660 != (newmode = touch_get_mode("foobar", 0666)))  
    printf("  error: Wrong file mode %o when creating using mode 666 and umask 007\n",
           newmode);
   
  umask (orig_umask);
  return 0;
 
int main(int argc, char **argv)  
  [...]
  test_umask();
  return 0;
 

Sure enough. On NFS to a netapp, I get this result:

Testing POSIX/Unix sematics on file system
info: testing symlink creation
info: testing subdirectory creation
info: testing fcntl locking
  Read-locking 1 byte from 1073741824
  Read-locking 510 byte from 1073741826
  Unlocking 1 byte from 1073741824
  Write-locking 1 byte from 1073741824
  Write-locking 510 byte from 1073741826
  Unlocking 2 byte from 1073741824
info: testing umask effect on file creation

When mounting the same directory using sshfs, I get this result:

Testing POSIX/Unix sematics on file system
info: testing symlink creation
info: testing subdirectory creation
info: testing fcntl locking
  Read-locking 1 byte from 1073741824
  Read-locking 510 byte from 1073741826
  Unlocking 1 byte from 1073741824
  Write-locking 1 byte from 1073741824
  Write-locking 510 byte from 1073741826
  Unlocking 2 byte from 1073741824
info: testing umask effect on file creation
  error: Wrong file mode 644 when creating using mode 666 and umask 000
  error: Wrong file mode 640 when creating using mode 666 and umask 007

So, I can conclude that sshfs is better than smb to a Netapp or a Windows server, but not good enough to be used as a home directory. Update 2010-08-26: Reported the issue in BTS report #594498 Update 2010-08-27: Michael Gebetsroither report that he found the script so useful that he created a GIT repository and stored it in http://github.com/gebi/fs-test.

If you're following me on identi.ca you probably already know that I've been designing a small PCB for a USB-based SPI chip programmer named openbiosprog-spi. The main use-case of the device is to help you recover easily from a failed BIOS upgrade (either due to using an incorrect BIOS image, due to power outages during the flashing progress, or whatever). The device only supports SPI chips, as used in recent mainboards (in DIP-8 form factor, or via manual wiring possibly also soldered-in SO-8 variants). It can identify, read, erase, or write the chips. Of course the whole "toolchain" of software tools I used for creating the hardware is open-source, and the hardware itself (schematics and PCB layouts) are freely released under a Creative Commons license (i.e., it's an "Open Hardware" device). The user-space source code is part of flashrom (GPL, version 2), the schematics and PCB layouts are licensed under the CC-BY-SA 3.0 license and were created using the open-source Kicad EDA suite (GPL, version 2).
The schematics, PCB layouts, and other material is available from gitorious:

  $ git clone git://gitorious.org/openbiosprog/openbiosprog-spi.git

You can also download the final Gerber files (ZIP) for viewing them, or sending them to a PCB manufacturer. Some more design notes:

• The device uses the FTDI FT2232H chip as basis for USB as well as for handling the actual SPI protocol in hardware (MPSSE engine of the FT2232H).
• Attaching the SPI chip:
  • There's a DIP-8 socket on the device so you can easily insert the SPI chip you want to read/erase/program.
  • Optionally, if you don't want a DIP-8 socket, you can solder in a pin-header with 8 pins, which allows you to connect the individual pins to the SPI chip via jumper wires or grippers/probes.
• The PCB board dimensions are 44mm x 20mm, and it's a 2-layer board using mostly 0603 SMD components.

Basic usage example of the device on Linux (or other OSes supported by flashrom):

  $ flashrom -p ft2232_spi:type=2232H,port=A -r backup.bin (reads the current chip contents into a file)

Over at the main projects page of openbiosprog-spi at http://randomprojects.org/wiki/Openbiosprog-spi I have put up a lot more photos and information such as the bill of materials, the Kicad settings I used for creating the PCBs, the Gerber files and the Excellon drill files and so on. The first few prototype boards I ordered at PCB-POOL.COM (but you can use any other PCB manufacturer of course), the bill of materials (BOM) lists the Mouser and CSD electronics part numbers and prices, but you can also buy the stuff elsewhere, of course (Digikey, Farnell, whatever). I already hand-soldered one or two prototypes and tested the device. Both hardware and software worked fine basically, you just need a small one-liner patch to fix an issue in flashrom, but that should be merged upstream soonish. In order to make it easy for interested users to get the PCBs I'll probably make them available in the BatchPCB Market Place soonish, so you can easily order them from there (you do still need to solder the components though). Note: I'm not making any money off of this, this is a pure hobby project. All in all I have to say that this was a really fun little project, and a useful one too. This was my first hardware project using Kicad (I used gEDA/PCB, also an open-source EDA toolsuite, for another small project) and I must say it worked very nicely. I didn't even have to read any manual really, it was all pretty intuitive. Please consider not using Eagle (or other closed-source PCB software) for your next Open Hardware project, there are at least two viable open-source options (Kicad, gEDA/PCB) which both work just fine.

One of the most debated points at the DebConf&Debian BOF was money management. Let's talk about how it works in an ideal world, and then how it tends to work in practice. This post only talks about year-to-year management, I hope for another post talking about the complexities of budgeting within a single year.In an ideal world, DebConf fundraises all the money it needs to go on. There is a DebConf sub-team for fundraising, since Debian doesn't have its own fundraising team. This team make brochures and solicits sponsors - there will be another post about this by someone on the fundraising team.We do our best to raise enough money to cover the conference, but it's long and hard work. In the months leading up to the conference, we are almost always running short. However, in the end, somehow, it comes through by a combination of cutting costs and continued fundraising work.The money is held by various nonprofits like SPI in the USA and FFIS in Europe. They hold it in trust for Debian. I think most people on the DebConf team agree that this money belongs to Debian, but is earmarked for DebConf since it was fundraised for DebConf. In the past, the DPL has not been asked for permission to use DebConf-fundraised money to put on a DebConf, since that's always been kind of obvious that it's for DebConf.Planning how much it will cost is hard. Venue costs aren't always known in advance, and we don't know our number of attendees until late. There are many uncertainties, which will be described later. These questions are hard to answer, but not impossible. Most of they time things work out in our favor.At the end of the conference, we tally everything up. Usually(=always, as far as I know), there is a surplus. This surplus is important, since DebConfN+1 usually needs a little seed money to get started before the new funds start rolling in. Historically, this seed money has been used for DebConfN+1, since it was raised earmarked for DebConf.In practice, it works out mostly like this. We keep track of the money, and try to stay within our budget, and cut things when we need to.For the last two years (coinciding with the recession), we have expected a deficit in the months and weeks leading up to DebConf. In these cases, we asked the DPL for some money to be given from Debian general funds for DebConf, and we provide background on our fundraising and budget status for use in making that decision. Both times, the Debian funds went to ensure that we could get travel sponsorship out. Debian general funds are not used without DPL approval.Also, keeping all the paperwork straight is a hard task. We have limited people, and the budget-trackers are always doing many other jobs, too. Personally, I'm not convinced that we always know how much the exact post-DebConf surplus is and where it is (SPI, FFIS, ...) each year. It sort of gets morphed into the general Debian money, and then we know "we have (about) XXX surplus" and then use that amount as our starting seed for the next year, taken from wherever is convenient. If Debian gives money to help make DebConf happen, it's usually as a loan. However, this loan isn't tracked carefully year to year. Someone looked up numbers during the BOF and reported that Debian has given/loaned 50,000 USD to DebConf over the years, but it's hard to know just how accurate that is. For comparison, the total DebConf budget over those years has been close to 1,000,000 USD, as best I can figure.We've tried various types of accounting software with mixed success. They are a lot of overhead, and we usually revert to keeping track of things in spreadsheets.
Our goals for budgeting (being self-sustaining) are good and well agreed on, but the implementation is hard.However, it's a place where it is easy for dedicated volunteers to get involved. If you wanted to help to make this better, you could do a lot of good by watching #debconf-team and lists, making careful records of our cash flow and where it comes from and goes to. All money we spend is announced and documented on the lists, so the information is there. To really do a complete job, this person would need to remain motivated in the months after DebConf and wrap up all of the final payments. Preferably, we'd have the same person year after year.There are many more suggestions that both others and I could make, but I'll save those for later.Tags: debconf

Recently I was surprised to find that many of the rules I took for granted when dealing with an OpenPGP keyring, and the other activities associated with a web of trust, were new to some people I spoke to. These rules are born from a mixture of experience, accepted good practice, and wider reading, with a small dose of paranoia thrown in for good measure.

• Protect your secret keyring with file permissions. For GPG, your ~/.gnupg directory should not be readable by anybody else, including root (even though he could break in if he wanted). Mine is octal 700, and the secret keyring itself is 600.
• Create a revocation certificate, and keep online and offline copies (gpg --gen-revoke <keyid>). The revocation certificate is published to key servers by you in the event that you detect key compromise or loss. It s important that this is also well-protected, because the secret key is not required to upload it. Print a copy in bold and on good quality paper, so it will last a long time, and preferably keep them both off-site in a trusted location. Typing all those characters back in is a bore, but if your online copy fails it s better than being impersonated.
• Use a good pass-phrase, not a password. A pass-phrase is actually easier to remember than a string of random characters, without risk. It can be long enough to make brute-force attacks pointless, and if you re using the key a lot and can t be bothered to type it all the time, gpg-agent is a handy and safe tool. Your login password is not an acceptable pass-phrase for your secret key!
• Regularly refresh your public keyring from a well-connected keyserver. I detailed this in an earlier post; it s a case of calling gpg --refresh-keys once a week or so. This is the first line of defence against other people s keys being compromised, since without it you ll never know that your messages to them are now vulnerable. A well-connected server, like those in pool.sks-keyservers.net, matters since not all servers synchronise predictably.
• Rotate encrypting sub-keys regularly. This reduces the effect of a compromised key: if you rotate keys annually, a compromise only opens one year of mail. Small comfort, but every little helps. Don t delete the old keys though, just revoke them otherwise you won t be able to open mail from those senders who don t refresh their public keyrings.
• Keep your key offline and make a separated signing sub-key for day-to-day use. There isn t room to go into detail here, but you can export a signing sub-key with a relationship to your primary key material, so if it is compromised you can revoke it without losing all those carefully-collected signatures. The same goes for encrypting sub-keys. Adrian von Bidder has a guide to this, but he warns that it should be taken with a pinch of salt, so this isn t so much a rule as an interesting idea. I have not experimented with this yet.

And some rules about signing and signatures:

• Don t place too much store by signing parties. Parties are great for rapidly building a web of trust, but a part of that trust is to do with how the other party checks identities. I don t believe it s possible to establish that with just a few minutes chat and an identity check, so I never make a sig2 or sig3 on a key I met at a party. I m usually happy to do that later when I have an established relationship with the key holder, of course.
• Never upload your own signature to a key server. Apart from the fact that the key holder might not want their key published, you also have no way to prove that the key holder has access to the email address on their UID. It s much better to send the signature to them encrypted, which demonstrates that they the both key and can read mail at the address (the caff program is ideal for this).
• Give personal trust (the trustdb) carefully. Getting that message Good signature from in your mail client is really nice, but not at the expense of giving away trust where it is not deserved. In the same vein as not placing too much trust at signing parties, you should avoid the temptation to over-trust keys in your personal trustdb. Reputation on a mailing list is absolutely no substitute for observing the party taking care over their verifications when doing face-to-face signings.

Do you have other rules or guidelines that you use when dealing with keys and signatures?

there was a recurring catchphrase during DebConf10, worded something like "Debian derivatives are also our users", that appeared quite often in talks as well as in hallway chats.

I kept pondering about this idea, & I'm still not sure what to think about it, & what the "message behind the message" actually is: is it an intelligent new point of view, some new way of thinking, seeing an increase in our user base & therefore in our possibilities&responsibilities? or, on the contrary, is it an admission of "defeat", accepting in resignation that end users prefer other distros, & Debian can only cling to the idea of "derivatives as users" in order to maintain its raison d' tre?

in the beginning I liked the idea ("oh, I haven't looked at it that way yet"); over time I tended to hear the defending undertone stronger ("if nothing else we are at least useful as a base for other distros").

the phrase might have both aspects; & I'm still not sure neither how it was actually meant neither if I like it ...

It has come up on the Planet recently, as well as the gnupg users mailing list: users need to refresh keys that they use to get updated information on revocations and key expiration. And there are plenty of examples of simple additions to ones crontab to set up a key refresh. Of course, with me, things are rarely that simple. Firstly, I have my GNUPGHOME set to a non standard location; and, secondly, I like having my Gnus tell me about signatures on mails to the Debian mailing lists, so I periodically sync debian-keyring.gpg into my GNUPGHOME. I add this as an additional keyring in my gpg.conf file, so that in normal operations gnus has ready access to the keys; but I do not care to refresh all the keys in debian-keyring. I also prefer to trust and update keys in my keyring, so the commands grow a little complex. Also, I want to get keys for any signatures folks have kindly added to my key and uploaded to the key server (not everyone uses caff), so just refresh-keys does not serve. Linebreaks added for readability.

# refresh my keys
# Note how I have to dance around keyring specification
45      4    *  * 4   (/usr/bin/gpg2 --homedir ~/.sec --refresh-keys
    $(/usr/bin/gpg2 --options /dev/null --homedir ~/.sec
      --no-default-keyring --keyring pubring.gpg --with-colons
        --fixed-list-mode --list-keys   egrep '^pub'   cut -f5 -d:  
            sort -u) >/dev/null 2>&1)
# Get keys for new sigs on my keys (get my key by default, in case 
# there are no unknown user IDs [do not want to re-get all keys])
44      4    *  * 5  (/usr/bin/gpg2 --homedir ~/.sec --recv-keys
    0xC5779A1C $(/usr/bin/gpg2  --options  /dev/null --homedir ~/.sec
       --no-default-keyring --keyring pubring.gpg --with-colons
         --fixed-list-mode --list-sigs 0xC5779A1C   egrep '^sig:'  
            grep 'User ID not found'   cut -f5 -d:   sort -u) >/dev/null 2>&1)

DebConf continued until Saturday, but Friday the 6th was my last day as I left New York that evening. I m a bit late in getting this summary written up. Making Debian Rule, Again (Margarita Manterola) Marga took a bold look at the challenges facing Debian today. She says that Debian is perceived to be less innovative, out of date, difficult to use, and shrinking as a community. She called out Ubuntu as the elephant in the room , which is taking away from Debian. She insists that she is not opposed to Ubuntu, but that nonetheless Ubuntu is to some extent displacing Debian as a focal point for newcomers (both users and contributors). Marga points out that Debian s work is still meaningful, because many users still prefer Debian, and it is perceived to be of higher quality, as well as being the essential basis for derivatives like Ubuntu. She conducted a survey (about 40 respondents) to ask what Debian s problems are, and grouped them into categories like motivation and communication (tied for the #1 spot), visibility (#3, meaning public awareness and perception of Debian) and so on. She went on to make some suggestions about how to address these problems. On the topic of communication, she proposed changing Debian culture by:

• Spreading positive messages, celebrating success
• Thanking contributors for their work
• Avoiding escalation by staying away from email and IRC when angry
• Treating every contributor with respect, no matter how wrong they are

This stimulated a lot of discussion, and most of the remaining time was taken up by comments from the audience. The video has been published, and offers a lot of insight into how Debian developers perceive each other and the project. She also made suggestions for the problems of visibility and motivation. These are crucial issues for Debian devotees to be considering, and I applaud Marga for her fortitude in drawing attention to them. This session was one of the highlights of this DebConf, and catalyzed a lot of discussion of vital issues in Debian. Following her talk, there was a further discussion in the hallway which included many of the people who commented during the session, mostly about how to deal with problematic behavior in Debian. Although I agreed with much of what was said, I found it a bit painful to watch, because (ironically) this discussion displayed several of the characteristic people problems that Debian seems to have:

• Many people had opinions, and although they agreed on many things, agreement was rarely expressed openly. Sometimes it helps a lot to simply say I agree with you and leave it at that. Lending support, rather than adding a new voice, helps to build consensus.
• People waited for their turn to talk rather than listening to the person speaking, so the discussion didn t build momentum toward a conclusion.
• The conversation got louder and more dense over time, making it difficult to enter. It wasn t argumentative; it was simply loud and fast-paced. This drowned out people who weren t as vocal or willful.
• Even where agreement was apparent, there was often no clear action agreed. No one had responsibility for changing the situation.

These same patterns are easily observed on Debian mailing lists for the past 10+ years. I exhibited them myself when I was active on these lists. This kind of cultural norm, once established, is difficult to intentionally change. It requires a fairly radical approach, which will inevitably mean coping with loss. In the case of a community, this can mean losing volunteer contributors cannot let go of this norm, and that is an emotionally difficult experience. However, it is nonetheless necessary to move forward, and I think that Debian as a community is capable of moving beyond it. Juxtaposition Given my history with both Debian and Ubuntu, I couldn t help but take a comparative view of some of this. These problems are not new to Debian, and indeed they inspired many of the key decisions we made when founding the Ubuntu project in 2004. We particularly wanted to foster a culture which was supportive, encouraging and welcoming to potential contributors, something Debian has struggled with. Ubuntu has been, quite deliberately, an experiment in finding solutions to problems such as these. We ve learned a lot from this experiment, and I ve always hoped that this would help to find solutions for Debian as well. Unfortunately, I don t think Debian has benefited from these Ubuntu experiments as much as we might have hoped. A common example of this is the Ubuntu Code of Conduct. The idea of a project code of conduct predates Ubuntu, of course, but we did help to popularize it within the free software community, and this is now a common (and successful) practice used by many free software projects. The idea of behavioral standards for Debian has been raised in various forms for years now, but never seems to get traction. Hearing people talk about it at DebConf, it sometimes seemed almost as if the idea was dismissed out of hand because it was too closely associated with Ubuntu. I learned from Marga s talk that Enrico Zini drafted a set of Debian Community Guidelines over four years ago in 2006. It is perhaps a bit longand structured, but is basically excellent. Enrico has done a great job of compiling best practices for participating in an open community project. However, his document seems to be purely informational, without any official standing in the Debian project, and Debian community leaders have hesitated to make it something more. Perhaps Ubuntu leaders (myself included) could have done more to nurture these ideas in Debian. At least in my experience, though, I found that my affiliation with Ubuntu almost immediately labeled me an outsider in Debian, even when I was still active as a developer, and this made it very difficult to make such proposals. Perhaps this is because Debian is proud of its independence, and does not want to be unduly influenced by external forces. Perhaps the initial growing pains of the Debian/Ubuntu relationship got in the way. Nonetheless, I think that Debian could be stronger by learning from Ubuntu, just as Ubuntu has learned so much from Debian. Closing thoughts I enjoyed this DebConf very much. This was the first DebConf to be hosted in the US, and there were many familiar faces that I hadn t seen in some time. Columbia University offered an excellent location, and the presentation content was thought-provoking. There seemed to be a positive attitude toward Ubuntu, which was very good to see. Although there is always more work to do, it feels like we re making progress in improving cooperation between Debian and Ubuntu. I was a bit sad to leave, but was fortunate enough to meet up with Debian folk during my subsequent stay in the Boston area as well. It felt good to reconnect with this circle of friends again, and I hope to see you again soon. Looking forward to next year s DebConf in Bosnia

MJ Ray has said that he needs occasionally to concatenate MP3 files and he wants those files to be free of junk in their middle. There are some nice things to say about this problem:

• Just using cat with MP3 files work because those files are headerless : the metadata in form of ID3v 1,2 tags is an addendum to the format. MP3 is also a format that can be conveniently used without containers/wrappers.That is not the case with AAC files, in general: AAC files that are not inside a container (e.g., Matroska or MPEG 4) are usually useless, unless you know (and can inform) some properties of them to th software that you are using. This is especially the case with AAC files that were compressed with some advanced things like spectral band replication (SBR).
• The tags for MP3 files (at least those in ID3v2) are supposed to be unsynchronized , so as to not be interpreted as audio data. What this means is that some byte sequences (a byte 255 followed by a byte with value at least 224) that are allowed as audio to say hey, I am a marker, process the
  next chunk of data, now have to be escaped if they are present in tags (so that you don t listen to garbage in the middle of a file i.e., you don t play the tag).

Related to this second point, the MPEG standards have a guideline that, if some data is not known by a decoder, for resilience purposes, it should be ignored. This obviously allows some newer features to be
implemented in a backwards-compatible manner and is nice. In other words, decoders should just skip those data and be done with it. Also regarding the second point, apparently, some versions of popular music players/manipulators have problems with unsynchronized data. There are many tools that one can use for removing unwanted, unsynchronized data from an MP3 file. For instance, you can use mp3diags, which is already conveniently packaged in Debian s repository. It is a recommended program for those purposes, indeed. There is another tool that serves that purpose as a side effect: mp3packer. Its purpose is, naively speaking, to losslessly shuffle the data inside an MP3 file so that it can be stored with fewer bits (saving more space for portable players, for instance). In the process of regenerating a new MP3 file, it discards some junk data and solves the original problem. Despite not being part of our repository yet, it is already packaged and
even a RFP bug exists.

This post concerns Romanian politics, internal affairs and improper direction of public funding for new hideous churches in spite of education, culture, health, technic development and old monuments. Thus I will write this in Romanian. Curious foreigners can try to read the text via Google's translation.

---

Din cauz c suntem n secolul XXI i consider c e o prostie imens s b g m bani n biserici n detrimentul educa iei, culturii, s n t ii, dezvolt rii tehnice i a vechilor monumente, iar politicul din Rom nia pare dornic s dea bani cultelor, am ajuns la concluzia c este cazul s -i scriu reprezntantului meu (teoretic) n Parlament, Deputatul Florin Iordache. Am aflat de ce colegiu apar in uit ndu-m aici i apoi n lista oficial cu deputa ii.




I-am trimis textul de mai jos:

M numesc Petri or Eddy i sunt unul dintre cei pe care i reprezenta i n Parlamentul Rom niei. Este pentru prima dat c nd scriu unui parlamentar care m reprezint n conducerea statului rom n i o fac pentru a-mi exprima n mod clar i r spicat ideile i opinia n ceea ce prive te subiectul pe care l voi discuta mai jos. Am 30 de ani, sunt programator, am muncit i mi-am pl tit taxele de c nd am fost angajat, din anul 4 de facultate p n n prezent, adic de vreo 6-7 ani. Nu, acest mesaj nu este un strig t de ajutor, nu a tept pomeni, nu am milogit niciodat , mereu am muncit de i v d c pentru unii parazitismul fiscal a devenit un mod de via . Din acest motiv sunt revoltat.

Sunt revoltat pentru c :
- de i pl tesc taxe i impozite care ajung la peste 60% din venitul brut, nu primesc n schimb nici un fel de servicii, nici un fel de infrastructur , nici un fel de respect, nici un fel de eficien
- de i lucrez de ceva timp, am observat c pe unde am lucrat competen a i performa a erau o necesitate; n aparatul de stat nu este cazul
- de i sunt destui ca mine care pl tesc taxe i impozite, vocile noastre sunt ignorate i banii no tri sunt arunca i pe fereastr de cei ce administreaz fondurile colectate.

Domnule deputat sunt revoltat c de 15 ani de zile dispar n medie aproximativ 4 coli zilnic i apare, tot n medie, o biseric la fiecare 2 zile, iar asta se nt mpl cu accep iunea aparatului politic. Spitalul din Caracal, ca orice alt spital din Rom nia, e prost dotat, nu exist personal suficient, nu are fonduri pentru medica ie pentru pacien i, pe scurt, este un dezastru care e pe cale s se nt mple. i cu toate astea, banii se duc spre biserici. Se fac dona ii de coli i terenuri c tre biseric , n mod ilegal i abuziv chiar n jude ul Olt.

Ultima perioad n care religia a condus lumea s-a numit Evul Mediu i cred c orice om care a tr it m car 5 ani n secolul XXI poate s observe c nu religia ne-a adus mari beneficii, ci tiin a i tehnologia. n Evul Mediu tratamentul se f cea prin s nger ri , t ieri sub limb , scoaterea argintului viu i tot felul de alte supersti ii f r nici un efect pozitiv sau chair cu efecte negative.

ntre timp umanitatea a progresat i am descoperit medicina, curentul electric, am explorat universul, am aterizat pe Lun , am pus zeci de sateli i artificiali pe orbit , am aflat foarte multe despre univers i lumea care ne nconjoar , am inventat noi materiale (plasticul, p nzele impermeabile, kevlarul), am investigat lumea f r idei preconcepute dup metoda tiin ific , iar lucrul acesta ne-a mbun t it via a n toate aspectele ei. Sperant de via a crescut de la aproximativ 30-40 de ani n Evul Mediu, la 70-80 de ani n prezent, totul datorit tiin ei aplicate. Datorit tehnologiei i tiin ei pot s v scriu aceste cuvinte i tiu c vor ajunge la dumneavoastr , nu datorit unor incanta ii sau ritualuri, nu datorit telepatiei, de i mediul sta de transmisie se apropie foarte mult de ceea ce define te ca fiind telepatie :-) . Cu toate astea, unii consider c religia trebuie finan at pentru c e religie, nici m car pentru c ar avea programe sociale, contribu ii cuantificabile reale, nu, doar pentru c este religie.


Am citit foarte multe articole din pres , articole bine documentate, i am senza ia c tr iesc ntr-o lume incon tient c nd v d cum banii care ar trebui s ajung n drumuri, coli, spitale, cercetare, medicamente, programe sociale cu real impact, ajung n noi i noi biserici de beton n timp ce monumentele istorice, bisericile din lemn, m n stirile cu adev rat valoroase sunt l sate n paragin . Asist cu o senza ie de dezgust continuu la felul n care ne batem joc de cei ce ne salveaz vie ile, medicii, de cei ce ar trebui s ne fac educa ia, profesorii, de cei ce ne sting casele dac iau foc, pompierii, i, de felul n care ridic m misticismul religios la rang de virtute. Este de-a dreptul jignitor i aberant ca alfabetizarea tiin ific n secolul XXI s fie at t de joas nc t s avem 42% din popula ie care cred c Terra este centrul universului, s avem oameni care cred c astrologia este tiin ific , s NU avem nici m car o universitate n top 500 n lume, este jignitor s fim n permanen n coada tuturor clasamentelor pozitive i n fruntea tuturor celor negative.

Recent money.ro a publicat un articol n care esitma foarte conservator c averea Bisericii Ortodoxe Rom ne se nv rte la peste 3 miliarde de euro, are scutiri de impozite, are zeci de afaceri i cu toate acestea, statul continu s scuteasc cultele de impozite, ba chiar le ofer bani ntr-una. La o asemenea avere nu cred c mai poate fi vorba de necesitatea finan rii de c tre stat. Oamenii pot decide s doneze direct c tre bisericile lor bani i nici nu mai implic pierderile inerente ce apar datorit administr rii fondurilor de c tre stat.


Statul nu este un organ aparte, statul trebuie s munceasc pentru mine, cet eanul, iar eu sunt mpotriva acestui tip de batjocorire i napoiere voluntar a noastr ndreptat mpotriva noastr . Alexandru Ioan Cuza a secularizat averile m n stirilor nchinate celor de la muntele Athos, deci unor ter i extreni rii, a a cum afl m din scrierile istoricului A.D. Xenopol, deci nu exist nici o obliga ie a statului s finan eze o institu ie anacronistic :

A.D. Xenopol Domnia lui Cuza Vod Vol.I , CAP. VIII. AI doile minister Cogalniceanu Secularizarea , pagina 291:

Nu vom atinge de c t mprejur rile care au condus la redob ndirea averilor, ajunse n st p nirea c lug rilor str ini, ating nd chestiunea nchin rei m n stirilor p n ntene c tre acele din R s rit, numai ntru c t va fi de nevoie, spre a n alege m sura seculariz rei nsu i.

Din aceste motive i multe altele, deoarece sunte i i reprezentantul meu n Parlamentul Rom niei, v cer ca s vota i pentru proiectul de lege ini iat de domnul Prigoan n ceea ce prive te t ierea finan rii personalui clerical de c tre stat i c t i a altor legi care ar putea duce la eliminarea privilegiilor pe care le au cultele, n condi iile n care singurul motiv real i corect pentru care o entitate ar putea beneficia de scutiri de taxe sau privilegii fiscale sunt doar cele ce nu urm resc interesul financiar i, totodat , au un impact social cuantificabil n mod clar.


Dac dori i, a fi bucuros s v r spund la eventualele ntreb ri sau neclarit i n ceea ce am scris, dac este nevoie.

V mul umesc anticipat!

L-am trimis joi, nc n-am primit r spuns de nici un fel. Pasul doi e s sun. M car s nnebuneasc dac tot sunt nesim i i. A a c , pute i afla de ce colegiu apar ine i i apoi pute i identifica pe cel/cea ce v reprezint n Parlament. Scrie i-le, suna i-i, a venit momentul m car s se enerveze, dac nu s - i fac m car o poleial de datorie.

Even in the modern times of AJAX, Web 2+ and what not, Elinks is one of my favourite browsers, at least for browsing some sites. The reasons are simple: it cuts the unnecessary distractions, and allows you to digest text based information rather quickly. In addition, since it doesn't display any images or flashy elements like Flash, pages load lightning fast even on poor connections, making it an excellent option.Unfortunately, some sites don't really work very well with Elinks, and for those, I do one of two things. For the ones which are really complex, such as secure login sites with too much AJAX, I just resort to one of the "standard" graphical browsers. For some others, I try to work around the problem using Elinks' rich scripting interface available in many programming languages including Perl and Ruby. I chose Lua, since it seemed simple enough to learn. I wanted to share with you some of the simple workarounds I implemented for some sites I visit often.The first quirk is with the Debian BTS, whose CSS isn't properly interpreted by Elinks (see 593804 and 593840 for details). The short story: the BTS renders like this:So, I grabbed the CSS, and made some small changes (described in the above mentioned bug reports), and got a new CSS file. I put it in /home/kumar/Kumar/bugs.css, and added the following to my ~/.elinks/hooks.lua:

-- Use an alternate CSS for the Debian BTS to work around some quirks
function debian_bts_format_html_hook (html)
   return string.gsub(html, "/css/bugs.css", 'file:///home/kumar/Kumar/bugs.css')
end
function pre_format_html_hook (url, html)
   if sstrfind (url, "bugs.debian.org") then
      return blonnet_format_html_hook(html)
   end
   return nil
end

and with it, the BTS renders like this:Much more readable!The second simple example, for which I won't include images, is the Mobile Twitter interface. The mobile Twitter interface is very convenient and functional in Elinks; however, by default, the text font seems to be a light grey, which is not discernible in the bright background. A default user.css file would be a possible solution, but I have not decided whether to go for it just yet. So, for the Twitter site, I add a function like this:

-- Make the status messages black on Mobile Twitter
function mobile_twitter_format_hook(html)
   return string.gsub(html, ".status.- ", '.status  word-wrap: break-word; color : #000; ')
end

And alter the actual hook function to:

function pre_format_html_hook (url, html)
   if sstrfind (url, "bugs.debian.org") then
      return debian_bts_format_html_hook(html)
   elseif sstrfind (url, "mobile.twitter.com") then
      return mobile_twitter_format_hook(html)
   end
   return nil
end

Finally, a more complicated example. I like reading the Indian business newspaper the Hindu Business Line. However, if you try browsing to the site with Elinks, you'll notice that, barring the top hyperlinks in each sectcion, the links on the left are not "linked" at all.In addition, there are some other irritants which are easy to remove, such as the navigation bar on the top, and the text colour being too light for my taste etc. So, I write the following Lua blurb. Why I write this is left for the interested readers to figure out, though it shouldn't be surprising if you open the page. The workaround for the missing links is interesting, though; it is because the website authors have put a hyperlink (<a>) tag before a list item (<li>) tag, and Elinks seems to not like that too much. So, I just swap the two around, and Elinks is happy.

-- Reformat the Business Line website
function blonnet_format_html_hook (html)
   html = string.gsub(html, "<body ", '<body text="#000000"') -- I like the text in black on the white background
   html = string.gsub(html, "<[Ff][Oo][Nn][Tt] class=leftnavi color=brown>.-</[Ff][Oo][Nn][Tt]>", '') -- An ugly hack to remove the navigation bar
   html = string.gsub(html, "<TD align=left vAlign=top width=\"500\"><IMG.-</FONT><BR>", '', 1) -- Remove description
   html = string.gsub(html, "<A class=groupnavi href=\"http://epaper.thehindubusinessline.com/\">.-</FONT><BR>", '', 1) -- Remove other group links
   html = string.gsub(html, "(<[Aa] class=navi.-)<li>(.-</[Aa]>)", "<li>%1%2</li>") -- Fix the erroneous section sidebar
   return html
end
function pre_format_html_hook (url, html)
   if sstrfind (url, "blonnet.com") or sstrfind(url, "thehindubusinessline.com") then
      return blonnet_format_html_hook(html)
   elseif sstrfind (url, "bugs.debian.org") then
      return debian_bts_format_html_hook(html)
   elseif sstrfind (url, "mobile.twitter.com") then
      return mobile_twitter_format_hook(html)
   end
   return nil
end

And here's the old and new rendering:

...awesome. OK, I'm writing this while I'm still in USA, but there are so many things to say about these weeks that I can't write them in only one blog post. And, still, this one will be quite long as it will talk about hacking, running and sightseeing...:) Let's start about hacking: after all, this is the first reason for being there in US, isn't it? I cam to DebConf with a very long TODO list and, for the first time in seven DebConfs, I'm pretty happy with what I achieved from it:

• samba packages
  • I (shortly) discussed with Steve Langasek about samba packages. He will have to talk with upstream about 3.6 that unexpectedly drops symbols in libraries , so that we can upload it in experimental (and probably also offer a lenny backport)
  • We didn't decide yet about the version to have in squeeze. I know, the freeze happened in the meantime, so we should stick with 3.4.8 but I'm more and more convinced that we should have 3.5.4 instead as upstream should stop supporting 3.4 security-wise around June 2011. I think I can convince the Release Team that 3.4-3.5 upgrade is not to be disruptive with the freeze.
  • I hopefully fixed the 3.5.4 packages for lenny which we have in our unofficial repository at http://pkg-samba.alioth.debian.org. I didn't take time to check this properly, though, so feedback will be appreciated.
• Pootle/translate-toolkit/virtaal
  • These are usually maintained by Nicolas Fran ois but he has no time for them. So, I agreed with him that I would release new upstream versions
  • pootle 2.0.5 is now in unstable. I have to work on an RC bug, still
  • translate-toolkit 1.7.0 is now in unstable too
  • virtaal: I began working on new upstream release packaging
  • backporting: I planned to backport translate-toolkit and pootle as there is a strong demand for them for lenny servers but the above mentioned RC bug prevented me to do so
• D-I work
  • I partly reviewed and corrected the D-I l10n documentation
  • I reviewed and activated new debconf templates added by Otavio Salvador and Daniel Baumann to live-installer, then called for their translation
  • Support for locales with "@" in their name in localechooser: I looked at this but I need someone more clever than me in shell scripting to fix that. Until that's done, I deactivated Serbian (Latin), unfortunately.
• Various packaging work
  • New release for console-data (mostly l10n stuff aimed for D-I)
  • Uploaded ttf-dzongkha and ttf-inconsolata to s-p-u to fix two RC bugs in stable
  • Polish tasksel and have Otavio to upload it
  • Checked my own packages against Rhonda's list of RC bugs in stable
• Localization work
  • Pootle upstream French translation completed, for 2.1.0
  • Cleaned out the tracking robot for French l10n in Debian

As one can see, a lot of planned work happened while I still could maintain the usual flow of recurrent work with localization (Smith reviews, l10n NMUs). Some asked me why I didn't propose l10n sessions this year. Indeed, I wasn't feeling I could sustain animating them and I had no clear idea about which topic I could bring to be discussed. Last year, these sessions slightly killed my free time and I wanted to keep some this year for "impromptu" things. I didn't attend many talks, sorry for the speakers. The most I attended were during Debian Day, which I found highlyinteresting and motivating, just like Eben Moglen's talk. Marga's talk was also one I wanted to attend, though I regreted that things went mostly out of control during the talk (too many comments from the audience to allow Marga pushing her important points). As usual, I invested a big part of my time in "social" activities, the most proeminent being of course the Cheese and Wine party, which turned ut to be a great success. The help of my son Jean-Baptiste and the tremendous support of Michelle Lynn Hall helped a lot, though I still regret that we screwed about accessibility. I also ran a lot..:-)..that may be counted as social activities as I organized several group runs. The one I'm proud of has been participating to a local race, namely the Van Cortland Track Club Summer Series of cross-country running, in Bronx. We went there with no less than 10 DebConf participants and 1 kilt (hey, Luca!). All of us completed the race (that had 170 runners for 5 kilometers) and No l K the even finished 17th scratch and 2nd in his age/gender category. Besides that, we had a great run/sightseeing to Georges Washington Bridge (that links New Jersey and Harlem and offers an unusual view of Manhattan "from behind"). All this with a 17km run. We also ran several times in Central Park, and No l and me happened to go to Coney Island for the Day Trip by doing half of the trip by running (all around Manhattan and over the Broolyn Bridge), for about 20km. Then we "showered" in the Atlantic Ocean....:). At the end of DebConf, I think that I had my record broken with 112km run in 10 days and only one day *without* running. What about sightseeing? Well, this blog post is too long and we reach the end of Interstate-90, close to Albany, so that will be for an upcoming blog post. Aug 25th update: back home, so now I can publish this blog post...

In a previous post I mentioned split debugging info. One addendum to this is how symbols are handled. Symbols are separate to debugging info (i.e. the stuff about variable names, types, etc you get when -g is turned on), but necessary for a good debugging experience. You have a choice, however, of where you leave the symbol files. You can leave them in your shipping binary/library so that users who don't have the full debugging info available will still get a back-trace that at least has function names. The cost is slightly larger files for everyone, even if the symbols are never used. This appears to be what Redhat does with it's system libraries, for example. The other option is to keep the symbols in the .debug files along-side the debug info. This results in smaller libraries, but really requires you to have the debug info files available to have workable debugging. This appears to be what Debian does. So, how do you go about this? Well, it depends on what tools you're using. For binutils strip, there is some asynchronicity between the --strip-debug and --only-keep-debug options. --strip-debug will keep the symbol table in the binary, and --only-keep-debug will also keep the symbol table. Of course, you can then strip (with no arguments) the final binary to get rid of the symbol table; but other than manually pulling out the .symtab section with objcopy I'm not aware of any way to remove it from the debug info file. Constrast with elfutils; more commonly used on Redhat based system I think. eu-strip's --strip-debug does the same thing; leaves the symtab section in the binary. However, it also has a -f option, which puts any removed sections during the strip into a separate file. Therefore, you can create any combination you wish; eu-strip -f results in an empty binary with symbols and debug data in the .debug file, while eu-strip -g -f results in debug data only in the .debug file, and symbol data retained in the binary. The only thing to be careful about is using eu-strip -g -f and then further stripping the binary, and consequently destroying the symbol table, but retaining debug info. This can lead to some strange things in backtraces: Note one difference between strip and eu-strip is that binutils strip will leave the .gnu_debuglink section in, while eu-strip will not:

Did the global climate change in 1975? Tamino has a nice blog entry on statistical analysis of temperature changes, showing a kink in the upward curve at 1975. This has been seen in a number of places, but no clear atttribution to a climate-state-change has been physically identified: perhaps its due to cleaner air, with aerosols removed in the 1970's. Recently, a colleague Dr. Shiyu Wang at ICHEC did some work on a more local problem: has the climate changed recently in Ireland ? Over the last three years we've seen record-breaking rainfall during the winter: in November 2009, many parts of Ireland saw twice the usual rainfall, in some places threefold increases. After three miserable winters, people were asking: is this the new norm? So Shiyu did some analysis for the Environmental Protection Agency, and the short answer is: it appears to be just a statistical fluctuation, for the moment. More would be needed to confirm a trend (you can see a poster presented on this here). But as part of this, he demonstrated that we did shift to wetter weather from about 1978 onwards. How can clearer skies over Europe cause this? another piece of the global warming attribution puzzle? Tags climate, ichec, precipitation, rainfall

Released just a few hours ago:

We are pleased to announce this maintenance release of xf86-video-geode. It features a plethora of bug fixes, a few documentation updates and one performance enhancement. This release also marks the return of Advanced Micro Devices to the development team. Please read the content of NEWS for more details.

In practice, this Geode 2.11.9 release mostly fixes the growing number of rendering issues that were exposed with each successive release of the X.org server core. Among other things, it restores the ability to correctly view video streams on Totem and other media players, it fixes icon rendering bugs that affected various desktop environments and web browsers, it removes all remaining compiler warnings and, as a byproduct of fixing one rendering issue, the speed of our driver improved dramatically. This is one release that will definitely please users of the OLPC XO-1 and of thin client hardware running on LTSP!

Since I started using Linux I've used several window managers. I felt used to blackbox and fluxbox and eventually used enlightenment and some others in the past, but nowadays its been a while since I became the user of an Desktop Environment. I'm using GNOME because it provides what I need and I don't need to spend an hour to configure it before it suits my needs. After all I'm lazy.
With respect to the fact that I'm quiet satisfied with GNOME, there is one feature I were always missing.
Because I spend much time with tiling and arranging windows on my desktops I noticed that I could need
a tiling feature. Something which was already a feature back in Windows 3.11.
GNOME/metacity does not have this features and given that a wishlist bug about this is open since almost 7 years
its unlikley that this will ever change. There are separate tools, which I recently learned about that can assist me with this. For example the perl script 'wumwum'. But this seems to be the wrong solution to a real problem. Additional wumwum does not work properly with metacity and so I'd need to another WM anyway, which lead to the point where I started thinking about integrating a true tiling wm into GNOME... once again.

First, I looked into awesome, which is a window manager I used some time ago.
But documentation about configuring it is basically an API documentation, with no obvious entry point.
It seems to be the best to study the whole API just to set some simple settings (e.g. a padding for the GNOME panel and some always-floating applications). I even thought about learning LUA, because it seems like a language which is quick and easy to learn, but honestly if I need to study a programming language and a whole API documentation just to configure a window manager then IMHO there is something conceptionally wrong with that piece of software.
After all I came to Xmonad. This window manager is using Haskell and I fear I need to learn this language as well if I want to configure weird things. But the wanted scenario is well documented and documentation for more common configuration settings exists all over the place so that I don't really feel inclined to learn more then needed.
Remember? I'm lazy.

Now I'm feeling quiet happy with this combination. It didn't cost me much time to get used to the most basic keyboard shortcuts or setting the whole thing up. GNOME and Xmonad work together like a dream team. I feel more productive now. As an additional plus I reinstalled the vimperator firefox plugin, because with my new desktop environment I more often use the keyboard for ordinary tasks like switching between apps or desks and I felt beeing able to quickly operate firefox with the keyboard, too, would be a plus. Well, it is.

Yesterday I handed out how to vote (HTV) cards for the Australian Greens. The experience was very different to the one I had when I handed out cards for the Greens in the Victorian state election in 2006 [1]. The Labor party (ALP) hadn t spread any gross lies about the Greens and there were no representatives from the insane parties (Family First and Citizens Electoral Council/Commission (CEC)). So we didn t have any arguments among the people handing out the HTV cards. The atmosphere among the volunteers that were present was a good match for some ideals of a sporting contest. Everyone wanted their own team to win but acted in a sporting manner. When no voters were around we had some friendly conversations. One thing that was interesting to note was the significant number of families where the parents in their 40s deliberately snubbed me while their children in the 18-22 age range took the Greens cards. It seemed that for families with adult children there were two likely voting patterns, one was children voting Green and parents not liking it, and the other was when the entire family voted informal (when someone refuses all offers of HTV cards it s a safe bet that they will cast an informal vote). In Australia submitting a vote card is mandatory but making it legible and formal is optional. The last report I heard suggested that about 5% of the total votes were informal. This seems to be strong evidence showing that civics lessons are needed in high school. Also there were a disturbing number of people who stated that they didn t know which party to vote for when they were collecting the HTV cards. A HTV card has one or two sentences about the party and there are almost no requirements for truth in such statements. Anyone who votes according to such brief summaries of the parties is quiet unlikely to end up casting a vote that gives the result that they desire. The result of the election is a significant swing to the Greens, more senators and the first Green MP! For the lower house it seems that Labor will have great difficulty in forming government even when in a coalition with the Greens and some independents. It seems unlikely that the Liberal party could ever make a deal with the Greens, the Liberal position on almost every significant issue contradicts that of the Green policy, but there is a chance of a Liberal coalition with independent MPs. In any case it seems that the Greens will have the balance of power in the senate so the excesses of the Howard government can t be repeated. If you like the nail-biting drama of watching several columns of figures slowly changing over the course of several days then you would love watching the analysis of this election! Whatever coalition government is created is not likely to be stable and we can probably expect another election in a year or two.

• [1] http://etbe.coker.com.au/2006/11/26/supporting-an-electrion-campaign/

(this is a post in two parts) At the BoF of GPG Key Management: Best Practices, dkg had two immediate recommendations for improving WoT resilience:

• Regularly refresh your local keyring from the key servers;
• If you have spare space and transit, provide a key server to take part in the pool.

Regular Refreshes This is important because unless keys are refreshed, changed expirations and (more importantly) revocations on keys are never made known to you. Making regular refreshes is easy, though I was surprised to hear people had experienced difficulty with it it s a simple entry to cron, like: 0 0 * * 1 /usr/bin/gpg --refresh-keys to run at midnight on a Sunday, or any other convenient time. Append > /dev/null to make it silent unless there are errors. Provide a key server This is nearly as trivial a refreshing the keyring, but it does take some disk space (on my machine, 4G for the decompressed dump from another server, 7.4G for the database itself and a few hundred MB for other stuff. Supposedly the dump can go after a full database build, but as I m not constrained I haven t bothered). The sks package in Lenny and Squeeze manages the database and answers to clients. However, take care to follow README.Debian carefully, since if the permissions on /var/lib/sks or /var/log/sks aren t set right it will silently fail and much head-scratching will ensue. Building the database for the first time takes some hours even on a reasonably quick machine, and takes a lot of CPU time, so it s probably best done overnight. Once sks is running, it needs to catch up from the date of the key dump to now (which is why a recent dump is always a good start). To do that, it should be listed in the pool.sks-keyservers.net and therefore needs gossip peers. http://code.google.com/p/sks-keyserver/wiki/Peering is an excellent guide, though the version of sks in Lenny does not support multiple listening addresses for either the recon or hkp processes. When a small enough delta between the server and its peers is reached, it s included in the DNS pool for use by other clients.

As you may remember, our co-op is working on various RFID (radio tags instead of barcodes, basically) extensions for Koha. One of the main ethical concerns about RFID is privacy if done wrong, it could become quite easy to see what books from which libraries someone has in their bag, without their consent and without physical contact. If borrower cards themselves become RFID-enabled, you might even obtain their personal data pretty easily, although I m not aware of any libraries in practice who put any personal data onto the borrower card tags yet. On 12 May 2009, the European Commission Recommended privacy and data protection in all RFID applications. That was followed by EU Mandate M436 for the European Standards Organisations (ESO) to develop standards to support that recommandation. Phase 1 started last March and has delivered a document RFID-DTR07044v006-draft (PDF). Phase 2 will build on that to produce formal standards for signage, privacy impact assessments and so on. EDItEUR are replying to that draft on behalf of the library sector and have sent me their draft response RFID_LibrarySectorCommentsDTR-07044-1 as a PDF. It s worth opening those two side-by-side to read through. If you can help improve the combined response, please send feedback to the email address in the Library Sector PDF by 6 September. If you d like to make your own response, you have until 15 September to reply to the ESO PDF using their template. By the way, does the ESO PDF look jaggy to anyone else? It looks like ghostscript can t anti-alias the text.