Search Results: "cas"

10 September 2006

Petr Rockai: weekend with family

So i have travelled to Slovakia again, for a weekend this time. I have been painting window frames. Since i have a new iPod (4G nano, black, yummy), i could also listen to music (Tristania, In Flames, Kamelot). The last time, it was somewhat of a patience exercise, but this time... I guess i got better at painting and maybe i have become more patient, too :). It was pretty enjoyable, more than i would have thought a work like that could be. And i am sure the music helps, too. (The next day) And to continue the last blog... There, i have concluded that hardship was important factor in becoming better: And apart from hardship... Problem is, hardship alone, if it stays the same, is not enough to make people change. It is the change from contentment to unhappiness, that drives people forward. Because in that change, one starts to change, and hardship together with dynamics helps a lot. Static, unchanging hardship will only do little to change a person. One can get used to it, like to anything else. Like to contentment. So an initial change can start a cascade. Like for me, breakup caused a domino effect. The change alone brought a lot of hardship with it, and i had to change to accomodate to it. And the change in me provoked more changes and so on. I have learned many new things, or, things i have learned before but went unnoticed took my notice. And in light of such things, i had to change again, because i knew i couldn't be happy any other way. A human being is as good as dead, when captured in a period of stagnation, in an unchanging moment that lasts. Only through change, through dynamics of life, we are alive. A man that does not change is a statue, a dead piece of matter, only useful as a memento. And that was what i have become, and now the statue is again starting to move, to breathe, to live. Because there is just no perfection that one could capture in a moment. No matter how perfect a moment, if frozen, the perfection decays, the little cracks are noticed. That is why trying to freeze time is futile, trying to preserve. One cannot enter the same stream twice. Life is a constant change, and this constant change is its only manifestation. Take the change away and you take the life away. The past is important. The past is what resulted into present, and present is what makes future. Every moment, in a succession of moments, is important. But without the moment before and the moment after, the moment does not mean anything. The moment is void, without predecessor and successor. We move in time, and the motion is what becomes important, not the points we moved through. They are only important in the relation to our trajectory, not in isolation. And so is the direction which we take, the vector of our motion, and the shifts in direction. There is no eternity, only the eternity of its own absence. Immortality and death are the same, the very same notion. Because every time we change, there is a little death and a little birth. And immortality is only possible in staticness. Immortality is a point in time, without motion. And without motion, there is no life to be. And same goes for relationships. Make a relationship immortal and you make it die. Relationship needs a possibility of death to live. Like humans, like every living being. Without death, there is no life. The transition from being into non-being is essential, because it is the precondition to change. As i have already described, every change is a death followed by rebirth, but the entity reborn is not the one that has died. And therefore, without the ability to die, there is no ability to change. And death, the conventional death, as we know it, is just a death without rebirth. Something dies, and there is nothing more to take its place. But... The death makes others change. And therefore, the one who dies definitively, is again reborn, as part of those others that have died, but haven't died, but are reborn. And the one definitely dead enters those new, reborn creatures, as a little fraction of them. And the cycle of life is closed, and the change can perpetuate itself. Every day, i die a thousand times. But there are deaths that are important and deaths that go unnoticed. And most of the important ones are only noticed in retrospect, by a being that resulted, after many hours, or days, or weeks or even longer. And many more deaths. We only exist through our succession, because only what is born from us remembers what we were. And the very moment we are born, we die again, and a new being remembers. The memory lives on, but the beings are already dead. And the memory changes as well, because memory itself does not mean anything, only the being possesing it can give it meaning. And every successive being that we become gives it a slightly different meaning. And so the delicate, complex dynamics of individual life are established. Not only the living being changes itself, but the memories of the previous beings change. There is certain gravity toward stagnation, because often the changes are only very slight, and the being remembers his predecessors that were fairly happy and tries to remain so. Because the bigger the change, the bigger risk. And therefore all beings are susceptible to stagnation, to the stasis cell of past success. Because past success is one's own enemy, even if it is something that is a precondition to one's own being. So we need to learn to live with our past success, but to not try to revive it. The effort to bring back past is a wasted, contraproductive effort. It seems so, it is almost natural, that if there was happiness in the past, restoring the same past will bring the same happiness. But there, that is not true, in the light of previous paragraphs. The trap is so obvious, that description is probably redundant, but let me do it once again anyway, maybe because i have fallen in it so many times already. Yes, the trap is in the stagnation, in absence of new things. Because even if one cannot restore the original condition no matter how much he tries, one can, and that is for sure, replicate it very closely. And that way lies a trap, a temporary (or even permanent) thermal death of stagnation. (Later that day, outside, on a nearby hill) And now, like before, there's nothing more to stand between me and myself. I sit in the grass, alone. My being alone complements me, in a way. There are waves in the grass, as air moves. Music is playing, apart from the few houses i can see downhill, my only connection with the rest of people. And this what belongs to me, this paper, this pen. This book by Italo Calvino that Enrico Zini has given me. If on a winter's night a traveller. But it is late summer. I can see vineyard in distance, on a slope different from mine. I call this slope mine because i am the one sitting there. And the time to collect the grapes is close. And here, next to me, an apple tree, with red apples on it. And a white butterfly in the distance, beating the air with its light, small wings. And i blow away a tiny spider who has lost its way on my trousers. I feel being part of all this around me, and still so foreign. And the butterfly appears again, but it may be a different one. The sun shines behind my back, alhtough i sit in shade of a tree. And neither the sun nor the tree are my enemies, or my friends. But still, i feel sympathy for both of them, one gives me light and warmth and the other shields me from too much of it. And the setting, the scenery soothes my senses, my mind, my feelings. Here, i am close to the loving mother of us, living beings, the nature. Here she is tender and forgiving and caresses my hair and it feels good. And these feelings, i would love to pass on, to other people, so they, too, could feel well. But i see that this is not quite possible. Although these lines will hopefully give something to someone, they probably can't carry what i feel. And i would bring someone with myself here, so they could feel it with me. But presence of other person would spoil it, it would be something else then. Maybe beautiful in a way, different from this one, maybe very pleasant. I love people, and when i see them happy, it fills me with gladness. (And in the evening, on a train...) And here i am, moving with speed, from one place to another. The speed, sound of loud music in my ears, the landscape drifting away. I could say i was happy, happy in the sense of change, everything changing around me, sun setting behind distant horizon, the train moving through the country. The semaphore lights. In the headphones, heavy guitar riffs competing with the roaring of the train. Cold air blowing in my face, flowing in my hair. And now in another train, sitting in a compartment with stranger, a girl, trying to guess who she could be, from her dress, from what she is reading, from cues. Who she could become. What she means to me, a passing stranger on the path of life. I have been reading the Calvino book till now, but i thought i could write down my thoughts before they perish, like they do. It is fairly silent now here, even while we are on a train. The engine and the outside are muffled, the window and the door are closed. We are in a strange kind of privacy with this girl, neither knowing anything about the other. I, writing this text here, she reading some sort of magazine. Looking up from what we do at occasions. The train is accelerating now, and the sounds are more intense. It is a bit shaky, too. My hearing is still lightly impaired from the loud music from the previous train. We arrived to a station. Short stop, then another long motion. Always toward Brno, toward my flat, toward the night and tomorrow. The girl is reading a horse races program. Here, i intrude her privacy and write that here. I hope she wouldn't mind. I don't have a name other than "the girl" for her, since all the words we exchanged was me asking whether i can sit down in the compartment and her answer. And i suppose i won't say anything and she won't, neither. Maybe a goodbye. And now, we share a sort of almost intimacy. Two lone people in a compartment, tired and waiting to arrive somewhere. An invisible bond between us, doesn't mean anything, just that element at random brought us there together, for a short moment. Chances are, we won't ever meet again. And still, she is almost falling asleep, with her feet up, like if i were a trustworthy friend of old. And i feel sympathy for that, i feel honoured by a trust given by a complete stranger. She seems comfortable, feeling safe. And it feels good to have that trust, it feels important. It nearly gives warm fuzzies. (To be continued, further...)

Joachim Breitner: Afraid of the German Police

Recently, a few hosted servers in Germany were taken by the police, some of which were running the TOR anonymizer (see heise.de, golem.de, both German). As I'm running one on my server, this worries me, as I am quite dependent on this server, especially now that I am in Ghana, my server in Munich and my backups behind a DSL line with anachaic little upstream bandwidth.I feel I should stand bold and keep running my TOR server, but in this case I'm a coward, so I disabled it. Sorry.For the uninitiated: TOR is a network of servers you can freely use to conceal the origin of your internet activities. This is invaluable for people with oppressive governments (more oppressive than the German one in this case); think China. Unfortunately, as with all technology, this can be used for bad things. The original reason for the police to seize the servers was, according to the news, child pornography. But they should know that a TOR server never knows both origin and target of a connection, and thus is useless for them!

Uwe Hermann: GPL confirmed in regular civil court in Germany

Good news for the Free Software world: From Harald Welte's blog, who started the gpl-violations.org project:
Today I have receive news that we've won the first regular civil court case on the GPL in Germany. This is really good news, since so far we've only had a hand full of preliminary injunctions been granted (and an appeal case against an injunction), but not a regular civil trial. The judge has ruled, but the details of the court order have not been publicised yet. I'll publicised the full details as soon as thus details are available in the next couple of weeks.
See also this Heise News article (German).

Robert Collins: 9 Sep 2006

Had a great time at Shane & Kates housewarming last night... learnt a bit about north-german humour, and spent some hours with conrad on the status of open source: We have an incredible amount of choice these days - 5 years ago C or C++ was the only default choice for high performance software. Now the boundary has shifted - a lot of high performance software can be written in highly productive languages, and there is robust open source Java support allowing software that needs more performance to be written with dropping down to the metal with C and C++. So C and C++ still have a place, but its becoming less and less the default, and more the special case. Even when C and C++ is chosen, it seems very rare these days that a new low level library is released without at least one of python/perl/ruby language bindings. So what does this mean? For most problems that one would like to write a program to automate, you can write it in a high level language and get acceptable performance on any computer bought in the last 3-4 years. And thats awesome.

9 September 2006

Andrew Pollock: [life/americania] Got to meet the Governator

One of our neighbours, Carol (the one who adopted Cleo, the mother of the litter of kittens we temporarily fostered a while ago), is a mad keen volunteer for the Republican Party (at the state level). I think Sarah mentioned I was interested in having a political discussion with her some time, so she invited us to come to a rally in Saratoga today and gave us free tickets (normally you'd have to pay at least $25 per person to do what we did). So we went along to check it out. It started about 45 minutes late, and we'd arrived 30 minutes early. It was in a high-school auditorium that held about 400 people by our guestimations. While we were waiting, it was interesting to do a bit of people-watching. The vast majority were Caucasian, and either young or elderly, not a lot in between. Those that were had children there as well. A few conversation snippets I overheard were people seeming to justify their opinions with themselves and each other, which was interesting. First up was some sort of attempt at crowd warming for a couple of minutes, then I think it was the state leader of the Republican Party who had a few words, then Arnold himself came on. He gave a pretty good spiel about how he'd unfucked the state since he took office, and how he needed to be returned for another 4 years, and rattled off a list of his accomplishments and what more he wanted to do. It was good to hear him talk about the environment, although in the next breath he went on to talk about "rebuilding California" and how there'd be cranes and concrete everywhere, with new roads and tunnels and whatnot, so you've got to wonder a little bit... In the same vein, he went on about not raising taxes or increasing spending, yet had this whole "rebuilding California" thing going on. His speech was generally fairly light-on details and more of a rousing the party faithful, than a "vote for me", I think. He wrapped up with an "I'll be back" and proceeded to throw some campaign swag into the audience, then came down off the stage to kiss hands and shake babies. I got to shake his hand, so that was the highlight of the whole outing. I certainly walked away from the rally thinking fairly highly of him as a candidate, even if he is a Republican. I'd be inclined to vote for him if I was entitled to. For the sake of hearing both sides, I'd like to go and hear what Phil Angelides has to say for himself as well. Some photos from the rally are here and a little bit of video is here.

8 September 2006

Carlos Villegas: A weird effect of discover (SoC2006)

It is funny to see that when I remove discover (/etc/rcS.d/S36discover) from the boot, a disk utilisation and cpu usage peak appear at the end of loading KDE. Would it be that discover is loaded by KDE if it wasn't loaded? Or a discover ghost :p. Well, the bootcharts for the two different cases are available here.

Andre Luis Lopes: Por qu Debian ?

Tenho aqui comigo um o in cio de um texto antigo, que comecei a escrever h uns dois anos atr s, sobre porque eu uso Debian. Nunca consegui finaliz -lo direito, mas achei que n o seria justo deix -lo aqui jogado em um diret rio empoeirado de meu HD (meu ~/txt tem muita coisa iniciada e n o finalizada). Um dia ainda vou termin -lo e acrescentar mais conte do, s preciso estar num dia inspirado para tirar todas as id ias da cabe a e coloc -las na forma de palavras. De qualquer forma, mesmo inacabado, espero que gostem. E lembrem-se : meu blog aceita coment rios :-)
Por qu Debian ? Eu tamb m ou o esta pergunta quase diariamente. Para que eu n o tenha que respond -la novamente a toda vez que me perguntem, resolvi sentar e escrever uma resposta padr o para a mesma. Assim, toda vez que algu m me faz esta mesma pergunta novamente, eu simplesmente pe o para a pessoa ler este texto. Aspectos t cnicos Qualidade. Sim, qualidade. Erroneamente, a maioria das pessoas que n o utilizam Debian ou que n o o conhecem pensam que o grande motivo pelo qual o Debian se diferencia das outras distribui es GNU/Linux puramente pela exist ncia da ferramenta APT, a qual auxilia na resolu o autom tica de depend ncias, facilitando enormente o gerenciamento de softwares. Realmente, trata-se de uma ferramenta extremamente til. Por m, atualmente, diversas distribui es GNU/Linu baseadas em pacotes no formato RPM (Red Hat, Fedora, Mandriva, etc) utilizam por padr o ou suportam, mesmo que n o oficialmente, mecanismos de resolu o autom tica de depend ncias e gerenciamento de softwares similares ao APT. Algumas at mesmo utilizam um porte do pr prio APT, adaptado para funcionamento com pacotes no formato
RPM. O que diferencia o Debian das demais distribui es GNU/Linux a qualidade. O apt-get a parte vis vel qual o usu rio tem acesso e que parece fazer toda a m gica. Por m, por atr s dele, existe um componente fundamental, frequentemente esquecido pelos usu rios : a pol tica de empacotamento de softwares Debian. O projeto Debian possui um documento extenso e altamente detalhado, que descreve, em cada m nimo detalhe, ao que um pacote de software precisa estar atento para poder ser considerado um pacote oficial e fazer parte da distribui o. A pol tica de empacotamento de softwares o que faz com que o Debian seja altamente superior s outras distribui es. Ela bem definida, clara e aplicada rigorosamente. Ferramentas de apoio aos desenvolvedores auxiliam a refor ar a aplica o das regras ditadas pela pol tica e qualquer pacote de software que n o siga fielmente o que dita o Manual de Pol ticas Debian n o inclu do em uma vers o oficial da distribui o, n o importando o qu o importante seja o componente de software fornecido pelo pacote. Isso, somado s diversas equipes internas existentes dentro do projeto Debian, garante a qualidade da distribui o. Equipes de QA (Quality Assurance), de seguran a, de ger ncia de release, ger ncia de relatos de erros e diversas outras equipes garantem que um sistema operacional funcional e altamente integrado seja criado, em oposi o a mera corre o de problemas em pacotes de softwares isolados. Adicionalmente, cada software passa por um intenso processo de avalia o antes que possa ser aceito oficialmente e adicionado a distribui o. Al m dos in meros detalhes t cnicos, tamb m existe uma equipe de especialistas legais que analisam as licen as de distribui o dos softwares antes de aceit -los como parte da distribui o. O fato do Debian ser atualmente a distribui o GNU/Linux que suporta a maior quantidade de arquiteturas de hardware que o kernel Linux suporta tamb m adiciona qualidade distribui o, uma vez que, como parte do processo de porte das aplica es para uma arquitetura de hardware suportada pelo Debian, in meras falhas s o descobertas e corrigidas, o que contribui
para a qualidade final do software. Logicamente, some a isso tudo o fato do projeto Debian possuir o maior acervo de softwares livres empacotados e prontos para uso existente da atualidade, deixando para tr s todas as outras distribui es GNU/Linux, inclusive as distribui es comerciais. Atualmente, s o mais de 15.000 pacotes de softwares prontos para uso e facilmente instal veis. Aspectos estrat gicos (ou independ ncia tecn logica) Uma das grandes vantagens estrat gicas que se ganha ao utilizar Debian a independ ncia tecnol gica. L gico, a grande maioria das distribui es GNU/Linux atuais s o livres, mas nada garante que continuar o a ser livres por toda sua exist ncia. Claro, sempre existir o grupos de pessoas dispostos a iniciar uma nova distribui o com base em uma vers o livre existente de uma distribui o comercial caso algo aconte a com a empresa que a desenvolveu e que impossibilite a continuidade da distribui o. Mas criar uma comunidade e manter um projeto grande como o de uma distribui o GNU/Linux, com toda a infraestrutura j fornecida pelo projeto Debian, leva tempo, anos. E consome anos de trabalho de milhares de volunt rios. O projeto Debian j tem tudo isso funcionando e uma experi ncia de 13 anos nessa rea. Exemplos de problemas com o envolvimento de interesses privados de empresas no desenvolvimento de distribui es GNU/Linux n o s o somente te ricos e recentemente tivemos provas da exist ncia dos mesmos, com empresas privadas terminando a continuidade do acesso a atualiza es de seguran as para suas distribui es de uso livre e sem custo e, em
muitos casos, praticamente obrigando seus usu rios a migrarem para vers es comerciais de suas distribui es. O projeto Debian criou o Contrato Social Debian. O item n mero 1 desse contrato social diz que o Debian ir sempre permanecer composto de 100% software livre. De igual import ncia, o item n mero 4 desse mesmo documento diz que a prioridade do projeto Debian ser sempre seus usu rios e o software livre, o que, na pr tica, garante que interesses comerciais n o ser o colocados em primeiro plano e que os usu rios n o ser o for ados a migrarem para vers es comerciais da distribui o em momento algum. A Defini o Debian de Software Livre, mais um documento produzido pelo projeto Debian, possui grande import ncia na comunidade de software livre, tendo sido utilizado como base para a cria o do Defini o de C digo Aberto (Open Sorce), a qual individuais e empresas aderentes ao modelo de desenvolvimento aberto de software usam como base para cria o de licen as de softwares que os qualifiquem como software aberto (Open Source).
Ok, isso por enquanto. Um dia ainda termino e acrescento mais conte do. Quem quiser comentar e dar novas id ias, esteja a vontade, nos coment rios ou por e-mail.

Martin F. Krafft: mutt tagging

Dear lazyweb: I love mutt, my faithful mail client for almost a decade now, but I think I've reached its limits. Not that mutt isn't doing fine, it's more my way of organising mail that's no longer working for me. To give a short overview: I receive all mail in a single account and filter messages to folders in a hierarchy. My filter set spans several thousand lines and has been growing for seven years now, the last "refactoring" was in 1999. When browsing mail, I either delete messages (for list mails mostly) or save them to the read folder when I am done with them. The hierarchy is mostly arranged by field of endeavour, and then subdivided into specific topics. For instance, I have =private/dudes/..., =debian/pkg/mdadm, =ul/phd, and =work/clients/.... I currently face two major problems with this approach:
  1. Folders just don't cut it anymore. For instance: with my job, research, and hobby all somewhat connected to Debian, most messages I receive don't belong into one folder any more than they should be in another. What I want is effectively what gmail and several of the GUI clients do: any given message can have a number of tags, and virtual folders act as filters to display only messages with a certain tag.
  2. Having a single sent and read folder for all worked for a while, but it's long been a major pain. What I really want is for sent and received mail to sit right next to each other in all cases, ideally based on tags as well.
I found mutt's X-Label patch (the Debian mutt package includes it), which seems to go in the right direction, but it's not exactly what I want (yet). For my purpose, it adds a selector ~y to use in searches and when limiting the display of a mailbox. Thus, I could implement virtual folders by saving all mail to a single folder (thanks to the header_cache patch), then executing l~ydebian to see all messages tagged debian. The problem with this approach is that it uses a functionality that I already use extensively: limiting. I like the thought of being able to use tags as filter criteria, but I don't want to depend on them. For instance, if looking at all messages with the debian tag, and then filtering those with mdadm in the subject, I currently have to hit l<space>~s mdadm (taking care to preserve the label limit), and I cannot use the simple_search functionality anymore. In the end, what I'd want is to be able to use the folder syntax for tags. Specifically, I think it would be cool to have folders as they are currently, but if you try to change to a folder that does not exist, or prefix the folder with vfolder (=vfolder/debian/mdadm), it would instead display the main folder with the different path components used as label filters. A syntax for logical OR would also be nice. All this should happen without affecting the limit functionality of mutt. I don't think this is currently possible, but before I start to pretend to plan my intent of eventually thinking about what it would take to have a go at coding a patch, I'd welcome your feedback. I can't imagine that I am the only one wanting mutt with tags... NP: Log / Every Time a Bell Rings, an Angel Gets His Wings Update: people have pointed me to Gnus and Mairix. I'll have to check out Gnus, but I wonder whether it can be used the way I do mail: currently, I use offlineimap (my favourite software award 2004-2006) to synchronise my Maildirs across a total of eight machines, so that it does not matter where I read my mail -- it's totally synchronised. I'll give Gnus a whirl soon though. Manoj already showed it (off) to me, and several other Debian developers seem to swear by it, so it can't be all wrong. With respect to Mairix, I know that tool; it basically populates folders with symlinks according to search criteria. One could say it instantiates virtual folders. The problem I have not been able to solve yet is quite simply that operations such as moving messages to other folders then operates on the symlink, which is not what I want, for obvious reasons. Even just using mutt to edit them results in a copy made, so the symlink association is lost. I'd be happy to be shown how to use the tool to make it do what I want. NP: Led Zeppelin / Led Zeppelin I

Dirk Eddelbuettel: More Comcast fun

One of the many recurring themes on this blog is the amount of trouble we're having with Comcast. So Ladies and Gentlemen, here is a new one: Having been forced to use the ISP as a smarthost for delivery (as reverse lookup is not provided for residential service), I depend on Comcast to deliver my mail. But look what we just got for attempting help a user on the quantlib-users list:
Reporting-MTA: dns; comcast.net
Arrival-Date: 8 Sep 2006 1:46:30 +0000

Final-Recipient: rfc822;
Action: failed
Status: 5.1.0 MAIL FROM: 550 REPLY:
550-"rejected_because_your_SMTP_server,_204.127.225.94,_is_in_the_Spamcop_RBL.
Diagnostic-Code: smtp; Permanent Failure: Other address status
Last-Attempt-Date: Fri, 8 Sep 2006 01:46:36 -0000
So a benefit of handing over around $500 per annum is that I do not get my mail delivered because the goods folks at sourceforge.net now think ATT Broadband aka Comcast [ to whom the address mail server 204.127.225.94 resolves ] is a spammer. Someone please remind me why I haven't switched to Speakeasy?

7 September 2006

Evan Prodromou: 21 Fructidor CCXIV

We got back from Europe 36 hours ago, and I've spent most of the time sleeping. We'd had a pretty rough flight across the Atlantic -- although of the three of us the baby was the least grumpy. I'm a terrible jet-lag victim, though, and just a few hours of time change really messes with my wp:biorhythms. Yesterday was Amita June's first birthday, and although we were all tired we had a good time just the three of us. My parents, Maj's parents and our siblings all called, and we picked up a few presents that had been shipped here while we were gone. Amita got a trip to the toy store (net haul: 1 rubber ball, one Caillou book, one crapload of block toys) and a special breakfast. Sadly, she and her papa fell asleep together before she got her birthday dinner. We're having a birthday party at our house on Saturday, "from 3PM to bathtime". It should be a little more lively than our quiet day at home. tags:

Malm I don't think I've posted anything in a little while, since before we went to wt:Malm . We had a really nice time while we were there. I had corresponded with Sean Finney, another Debian developer who lives in Malm , before we left for Europe, and he'd offered a meetup. We had a free day in wt:Copenhagen so I figured I'd take him up on the offer. Malm is only about 40 minutes from Copenhagen by train, so we were able to take a trip over quite easily. There's a beautiful bridge between wt:Zealand and wt:Scania which we crossed by train -- the water was beautiful. We managed to miss Sean at the train station -- I'd given some pretty tenuous instructions on how to meet us -- but we managed to get out and see the town a bit for ourselves. The old city has two squares -- the Stortorget or Big Square and Lille torg or Little Square -- right next to each other. The Lille torg is circled by restaurants and we had a decent lunch at a place called the Moose Bar -- Scandinavian staples like salmon with a Thai presentation. A good idea. Sean managed to catch us as we were walking around, so we had a nice coffee together at a caf on the main drag. He's been in Malm for more than a year, and is taking classes at nearby wt:Lund. We managed to exchange GPG key signature preliminaries (what Maj calls the "Debian butt-sniffing ceremony") and had a good time talking about the state of Debian and Free Software. We split up at the train station and Maj and I went off to explore the towns small castle. It has a number of museums, but it was late in the day on a Sunday, so we opted instead for a walk to the beach, looking out to the bridge and ultimately the skyline and wind turbines of Copenhagen. After a long walk circumnavigating Malm 's distinctive Twisted Tower, the tallest building in Sweden, we headed back to Copenhagen for a dinner at Tivoli Gardens (probably my favorite spot in Copenhagen). tags:

Z rich We made a special stop on the way home to Montreal through wt:Zurich. We flew on Swiss Air, which has a hub in Zurich, and they gave us a free 24-hour layover in town. Fortunately for us, we got to spend some time with our good friends Mark Jaroski and Allegra Biava. They're friends of ours from SF who moved to Switzerland around the time Maj moved there, and they now live in wt:Lausanne. Both are extremely funny, intelligent and clued-in people. They were passing through Zurich on their way back to the US for a family visit there. I'm glad we got to see them, since I got to meet No ma, their 2-year-old daughter. No was born about 8 months after we last saw Mark and Allegra -- they weren't even telling people they were pregnant at the time. She's a barrel of laughs -- a real fun little person. She and Amita June got along great. We spent most of our time walking around central Zurich, seeing some of the sights and taking it easy. There's only so much tourism you can do with one toddler, and two toddlers raises the requirements considerably. I think the big downer for Zurich for me was how many people we didn't see. I'd hoped to connect with Alex Schroeder, founder of CommunityWiki, and also Martin Krafft, another fellow Debianista. Most disappointing, we missed Marco Prestipino, who's doing work at the University of Zurich in information transfer in online communities. tags:

6 September 2006

Edd Dumbill: New home for Monopod

I'm pleased to report that Nickolay Shmyrev has taken over as the new maintainer of Monopod, my simple podcast client for the GNOME desktop.Monopod now has a new home page, and a publicly available Subversion repository. My thanks to Nickolay for taking this on.A new release is now available, which makes Monopod build with the latest ipod-sharp code. If you're in the market for a drop-dead simple podcast client, Monopod's still a great choice. 

5 September 2006

Gunnar Wolf: Official: The fraud is a fact.

Today, as it was widely anticipated, the Superior Tribunal of the Judicial Power of the Federation (TEPJF) declared Felipe Calder n, of the currently right-wing governing PAN party, elected as president for the 2006-2012 period.
My regular readers will know that my political views are against his party's, and that I completely oppose him - Of course, being consequent, in June I started, together with some friends, FeCal.org.mx, a site destined to show the incongruencies and incoherences in the official version - and that evolved to a site I am quite fond of, having good and deep analysis of the political situation. Of course, it is time now to redesign and think forward for this site, now that FeCal is no longer a candidate - but lets leave it aside for now.
Today, we are mourning. We are not mourning an electoral loss - Wherever there is democracy, there are losers, and it might be right that we lost this time. Furthermore, in political systems such as ours, it is practically guaranteed that the majority of the citizens will lose (this means, it is terribly hard for any candidate to get over 50% of the votes - If Calder n wins with almost 35% of the votes, or if L pez Obrador wins by a similar amount, we will anyway have 65% of losers). But what we are mourning goes far beyond that: We lost faith in our electoral institutions, which we were so proud of a couple of years ago. They proved not to be serious, not to be adequate for a hard decision. Why am I saying this? Lets analyze a bit.
First of all, the Federal Electoral Institute (IFE)'s main function is to organize the federal elections, and to make sure they are run with neutrality. Since the early months of the formal competition (as the campaigns themselves started way too early and we Mexicans are sick of the eternal electoral climate), the IFE has not acted in time to stop a dirty campaign, made not only by the PAN party but by the nation's President himself and by groups that, being privately owned, are said to be outside the reach of the IFE's regulatory spectrum. The IFE's general council should have been built with representants of all of the main political forces, but only PRI and PAN (which means, center-right and right wing) were represented.
Secondly, over the last six years, President Fox seems to have made constant efforts not only to prove us all he is a complete fool and inept as a statesman (examples abound, there is no rush to prove Vicente Fox just cannot be trusted to run a country), but that his fight for democracy was nothing but a race for personal power. He took every oportunity he could to promote his party - while the Mexican law requires him to remain neutral during the electoral period. There are many proven examples of irregularities and corruption inside his cabinet (most notably those carried out by Josefina V zquez Mota, who was in charge of all of the federal programs to fight poverty, and was the coordinator of Calderon's campaign) leading to inject resources into the campaign. Yes, this should have been stopped by IFE as soon as they were detected - But it was not. And, thank you Mr. Fox, by doing this you severely undermined the respect there should be for the Presidential figure.
Now, IFE's role ends shortly after the elections. After that, it is TEPJF's role to qualify the elections - To ratify they complied to the required equity, legality and certainty. Many of us had more trust in TEPJF than in IFE, mainly because of the series of personal and group connections that came up between IFE and the power groups. Most of us were quite vocal on the voto por voto, casilla por casilla front - Demanding from TEPJF to request to recount all of the votes. Having only 0.58% distance between the top candidates, with lots of statistical anomalities, with tons of reports of illegal tampering of the ballots, having a wide recount would surely make many among us believe and accept the results - Of course, the PAN repeated ad nauseam that the ballots had been counted and we should not go again over the same excercise, quoting all kinds of arguments that came from a too narrow interpretation of the law. And, in the end, too narrow was the response of TEPJF - Only 9% of the booths were reinspected, and not all of them were recounted. In fact, one week ago, they decided to discard over 300 appeals (this means, 300 requests for trial on a specific booth or on a whole district), without yet disclosing which appeals were they, on what basis were they discarded, what geographical areas did they impact, or anything. They nullified about 235,000 votes - And this number is quite scary, as it practically matches the official difference between the two lead candidates (244,000 votes before this partial recount, 233,000 after it). We can now state for certain that the difference between the candidates is smaller than the error margin.
Today, with a very important portion of the country in doubt on whether their decision was legal and correct, TEPJF ratified Felipe Calder n as the elected president. This would be good news. I would like to accept Felipe as my president - Sadly, I cannot, just because all of the TEPJF's principles were violated: So... In short, what comes now? We are exhausted by this long process. As too many people, I just cannot accept the imposition of yet another fraudulent president. I had the hopes that Mexico had changed in the last 18 years - But it has not. We are still in a strong presidentialist regime, and we still don't have hopes of getting a democratic government. If we do have a democraticly elected president, perfect, I will accept it. Of course, criticizing and keeping a close eye on his government, as I don't think the social and economic principles they push, but accepting. But there are too many signs of a fraud, there are too many stinky bits in the decision. The stinkiest of them all, the refusal of their opportunity to shut us up. Is it better to have millions of angry citizens closing important streets and giving Mexico a bad name by writing about our trip back to the stone age than to allow for a legal recount? Is it too much asking giving some certainty to our elections? Is there any doubt we will keep fighting this imposition?

Wouter Verhelst: Customization-modules

There's some discussion going on in Debian about firmware in main. Some people want it, others don't. The main argument by the firmware-in-main advocates seems to be that we can't install hardware if there isn't any support for it in the installer, and that the installer can only install by using stuff that is part of main. The obvious answer to that would be to modify the installer so that it would support retrieving stuff from non-free, but then that would require some changes to the installer which, according to Joey Hess, are rather significant. So we now have a GR proposal to allow for firmware in main anyway, so that we can support non-free hardware. Obviously the proposal includes overriding the social contract. And huge and insane flame wars. I don't like the sound of that. And I'm not convinced that the only way to get non-free udebs on a system is to download them from the Internet; Windows, RedHat, SuSE and other operating systems have supported the concept of "driver disks" for ages; I don't see why we couldn't do the same. And since our system is way more flexible than theirs anyway (it being modular and all), we can easily implement this using udebs. So rather than engaging in flame wars, I just sat down and wrote some code that would allow the concept of "customization disks": CD-ROMs, hard disk partitions, USB keys, or floppy disks with udebs on them that will be installed if the user chooses the right option in the installation menu (requiring expert mode to get there, however). This can be used for all kinds of interesting things: non-free modules, but also OEMs (say, HP) providing udebs on their driver CD-ROMs so that they can have the installer support their hardware which is supported by the latest version of the Linux kernel, but occasionally not by the version that Debian Stable ships with, by backporting a kernel driver to the right version. Should they so choose. Or people could use it to test new modules without having to upload them and without having to set up their own repository. Or third-party developers could use it to add extra code to the installer to support some automagic stuff, whatever. It hasn't been tested at all yet, but at this point it's not much more than a proof of concept anyway. Comments are welcome, but please read the thread on -boot on the subject, too.

Simon Richter: Wikis and structured data

I need to deploy a content management system that is to be used by a number of technically not overly savvy people, so I am thinking of basically using a wiki and locking it down. However, wikis' big strength is mostly unstructured information, like texts. However, in a few cases, I'd like to have a few database views on pages, or even a way to submit new data to a database from a form. So in essence, I need a wiki form of Access. Is there anything similar to that already, or is this entirely new territory?

John Goerzen: Another Haskell Solution to Lars' Problem

Yesterday, I posted an 18-line solution to Lars' language problem. One problem with it was that it was not very memory-efficient (or time-efficient, for that matter). In other words, it was optimized for elegance.

Here is a 22-line solution that is much more memory-efficient and works well with his "huge" test case. Note to Planet readers: Planet seems to corrupt code examples at times; click on the original story to see the correct code.

import System.Environment
import Data.List
import Data.Char
import qualified Data.Map as Map
custwords = filter (/= "") . lines . map (conv . toLower)
    where iswordchar x = isAlphaNum x && isAscii x
          conv x = if iswordchar x then x else '\n'
wordfreq inp = Map.toList $ foldl' updmap (Map.empty::Map.Map String Int) inp
    where updmap nm word = case Map.lookup word nm of
                             Nothing -> Map.insert word 1 nm
                             Just x -> (Map.insert word $! x + 1) nm
freqsort (w1, c1) (w2, c2) = if c1 == c2
                                 then compare w1 w2
                                 else compare c2 c1
showit (word, count) = show count ++ " " ++ word
main = do args - getArgs
          interact $ unlines . map showit . take (read . head $ args) .
                     sortBy freqsort . wordfreq . custwords

The main change from the previous example to this one is using a Map to keep track of the frequency of each word.

Kevin Rosenberg: CLSQL Version 3.7.1 Released

Provides a minor bug fix for AllegroCL's lowercase lisp reader, mlisp. Also, special thanks to Christophe Rhodes, frequent contributor to SBCL's MOP, for his excellent suggestion in response to a question for improving CLSQL's MOP internals: CLSQL object definitions use custom slot types. For example, a CLSQL slot may have :type (varchar 10) specified which gets translated to a lisp type of (or null string). Rather than parsing and then re-storing the type atrribute of a slot in compute-effective-slot-definiton, Christophe suggested performing the type parsing in initialize-instance :around of the CLSQL direct-slot-definition object. Then, the real type attribute is stored in the both the direct and effective slot definition from the beginning.This is more AMOP complaint since AMOP doesn't specify that one may change the type attribute of a slot. This is clearly seen since CLSQL no longer needs to modify OpenMCL's ccl:type-predicate slot attribute after the type was changed in compute-effective-slot-definition.

4 September 2006

Erich Schubert: More on the Debian board

Simon has a similar view of the situation. With the stuff I proposed in my last entry and earlier (e.g. bug masters) - I'm well aware that this means someone needs to write a lot of infrastructure code. But given recent improvements e.g. on our bug tracking (user tags, subscription, version tracking) this seems to be working okay. I've never really used launchpad, so I can't comment on what it offers that we might need and where it sucks. And I've said a dozen of times that I hate bugzilla. Next I'm usually hard to convince that any "infrastructure improvement" will help solving "social" issues. But here it might, if it "weakens" the formal DDs power (isn't god on how the software is packaged and on how patches come in) and strengthens the "occasional contributor" (pending patches repository, DDs can easily approve patches and trigger an upload without being deeply involved with the package, since NMUs are easier to do). And I'm also aware that my point of view isn't consequent. On one hand I'm convinced that any big "steering" won't work anyway, and those who do the job (read: write the code, write patches) will largely be those who set the direction. Linus didn't just pick a VCS and decide that everyone will have to use it, but actually wrote his own to suit his needs. And others liked it, picked it up, improved it. On the other hand I'm asking people to use packaging practises that allow others to easily contribute. I almost suggested to make it policy to use debhelper and CDBS... Well, it's one of the things I've learned myself: make it easy for others to contribute - and you'll enjoy it more, because more people will contribute. If it's hard to contribute, people will complain, will file bugs, will argue. If it's easy to contribute, they are more likely to send patches and enhancements. Read: more fun. It's also one of the reasons I blame for my SELinux work being not too rewarding: it's hard to get going, it's hard to contribute (well, that has improved with the public readable SVN repository for the policy). Less people, less contributions, less fun. Anyway, I don't see the need for any steering or "global picture". We're not lacking the big goals, but the low-level fun at development. That doesn't mean I'm strongly "opposed" to the commitee. I just don't see the benefits (but certain costs for electing it. Do we take group applications and vote among groups? Then we could just have the DPL nominate the steering comitee. Or will we vote on individuals, with the top n becoming the board? Then we'll have lots of platforms to read (=boring, not fun), and we'll probably have the same problems at a different level, different opinions in the board. And, given that the DPL has no real power, will the board have any? We also have a technical comittee. Does it have any power (well, it's supposed to, but was it ever enforced)? Did anyone ask it about something recently?

Simon Richter: Why we don't need a steering committee

Debian has always defined itself as "the universal operating system", which to me means that, given two options A and B, each with their own advantages and disadvantages, we will incorporate them both, because there are people for whom A is better, and people for whom B is better. This is one of Debian's greatest strengths, and this is what makes it the "universal" distribution. Now there has been discussion lately about whether Debian needs some sort of central authority to pull the project into a certain direction. The thing is, while everyone seems to agree that we lack direction, we cannot disagree more on which direction it would be if we had one. At present, we have a number of groups pulling in different directions:
The "release" group
Debian's primary goal is/should be to make stable releases. In the time between releases, people should run the release candidate and iron out bugs, so we can release faster; new features are to be added only right after a release.
The "usability" group
Debian does not have any use if we do not support every user. As the admin users can already help themselves, we should focus more on the average user and make the system more simple to use and administer. Integration is a must, as is closed-source firmware.
The "hacker" group
Debian's purpose is essentially to give us a distribution we can use for ourselves, where all the tools that exist are there.
The "freedom" group
Debian is supposed to be only free software so I don't accidentally come into a situation where I'm in breach of a license.
The "large installations" group
It should be as easy as possible to deploy Debian to a set of boxes and remotely administer them. It should be easy to install the software the users need and to customize it for our organization. Users are not supposed to administer machines, and non-free software and drivers need to be clearly marked and easily avoidable so as to not put us at legal risk.
The "supermarket" group
Debian is a repository of packages that makes our lives easier when we build either a system or a distribution, but we don't really care whether stuff is integrated already, because in order to feel comfortable with it, we need to redo it anyway.
The "small but beautiful" group
The system should be as modular as possible, allowing me to leave stuff out that I don't need. I don't mind installing stuff later on.
There are others, and I have represented each only with their most extreme positions. These groups are not usually disjunct, and in some places, some groups share goals. But, for example the "usability" group and the "small but beautiful" group will always disagree on what should be in a base installation. All of this is not new. What is new is that people are asking for a strong leader to strike down the unbelievers rather than discussing stuff on the mailing lists. This is generally a thing I wouldn't like to see happen in Debian, because anyone you pull into the discussion is either uninformed (so not qualified to answer) or already has an opinion (which will most likely conflict with either party's opinion). By forcing a decision, you essentially give one party the right to dismiss arguments with "we've already had this, it has been decided" and do not solve the problem at all, because the other party is still unhappy. You might want to argue that a committee evens things out a bit as more groups are represented there. That is true to a certain extent, however you'd have to have a way to determine who gets to be on the committee, and to do so in a manner that noone is left out (even if there are new groups forming all of the time) and without giving any group too much power. We might just include everybody, which brings us to status quo, except that everyone got a job title now and people might feel more inclined to decide things by majority vote (because that is what committees do after debating, right) instead of based on actual merit. Scott writes that implementing the same thing he just did in Ubuntu would have taken him ages to do in Debian because there are so many more people to coordinate in Debian. I have to disagree here, the number of people to coordinate is probably the same if not higher, except that the Ubuntu model seems to be that every core team member has commit access and is supposed to read up on the changelog when touching a package, making the coordination more implicit. I happily give out Ubuntu CDs, which do have non-free drivers, firmware and documentation, to users. Telling them that they cannot use that driver or have a manual because it's not free will not help anyone, and it is unlikely that they will be taken to court over it. This is all fine and dandy considering Ubuntu's target audience. However, Debian has a much larger target audience, including Ubuntu itself. If Debian were to interpret licenses less strict for some perceived benefit for the users (cdrecord springs to mind here), then all derivers, including Ubuntu, would have to carefully cross-check all of the licenses for possible violations. Thus, I oppose GFDL documentation in Debian main, because when we say "our priorities are our users and free software", that includes all of our users, not just end users. So, what I ask of you people reading this via Planet Debian is the following: Ask your "opponent" whether he'd be interested in finding a common solution that fits both use cases. Present it as a technical challenge. Accept that the outcome of such an endeavour might be that the other person is right. Accept that not everyone shares your views and/or priorities. It is hard to accept for me that a lot of people still think that svn is superior to git, or emacs is superior to vi. So if you have a different opinion on some matter, keep in mind that the other person may be looking at things from a different angle, where his choice is the only "logical" choice. Oh, and that goes for both of you. To conclude: Debian's strength is its lack of a clear direction. If we were to decide that the end users are what matters, we'd become another Ubuntu, which would be quite unnecessary because we already have one, and they are pretty good at being Ubuntu. If we decided only releases mattered, we'd probably release more often, but right after a release, unstable would be really broken (the elders might remember how it was before the "testing" distribution was introduced). In the same way, the release team takes care to include your pet project in the release if at all possible. Every package that is added delays the release because they have to wait for autobuilders and make sure that everything is internally consistent. So, they are already respecting your goals. Are you going to respect theirs, and join the release effort even if all your machines run unstable? So in my opinion it is a good thing that we did not decide on a direction, because there is no right one. We'd always leave some people behind if we had to make a choice. What needs to change is our attitude that software is to be used in one particular way, because the people actually using it would disagree. After all, free software is (also) about being able to do things your own way, and Debian as a whole should be supportive of that.

Erich Schubert: Debian board

The "Debian board" has been discussed a lot recently. I'm not so convinced it will improve matters that much. I don't think Debian is lacking a central authority to keep the vision. Most people have some overall vision; these visions might disagree on some points, but a board is bound to have the same disagreements. What is taking the fun out for me is not that some technical matters don't work out the way I want them too, but usually it's lack of manpower in certain files of particular interest to me. For example SELinux has been rather frustrating for me, since I felt like fighting alone on a lost position. Often applications would change faster than the policy could be updated etc. And trying to support sarge made that even more so. Sometimes bugs were fixed upstream, but the packages in Debian weren't updated yet, etc. When I was maintaining galeon back then, the must frustrating things were that on one hand, you had lots of people complaining about galeon 2 being different from galeon 1 (and not accepting that galeon 1 was dead upstream, I preferred galeon 2 and so obviously packaged galeon 2) - and on the other hand that there were tons of open bug reports noone even had time to verify. Working on such a package can be very frustrating. I've been keeping out of flamewars and such for quite some time, so I'm not so much bothered by that. I've blogged about that before. But I don't see where a "board" or "steering commitee" would come in helpful. Especially not in comparison to DPL-named release managers etc. IMHO it would be helpful to bring more people in. Our process of becoming a DD is very demotivating, and actually we could use more people - especially - for things like bug verification. Contributing to Debian can be demotivating for several reasons: Stuff I've been enjoing: What I'd love to see on the long run is some kind of central package repoistory. Many other distributions use some kind of huge version control system for managing all their packages. Maybe we could have something like this with two "default" branches. With very little effort you can get write access to the "public" branch, and only full developers can pull patches over to the "authorative" branch. Packages should be built from that branch, and use some uniform way for this (e.g. debian/patches/ directories!) But people with more experience in team maintainance, e.g. the Gnome team, can hopefully comment more on this.

John Goerzen: A Haskell solution to Lars' Problem

Thanks to a little glitch in planet, one of Lars' posts from 2004 came to my attention. In it, he proposes a test for language benchmarking:

Read text from the standard input and count the number of times each word occurs. Convert letters to lower case. Order the words according to frequency, words with the same frequency should be ordered in ascending lexicographic order according to character code. Print out the top N words, where N is a decimal number given on the command line. Each output line must contain the count, a space, and the word (in lower case), and end in an ASCII LINE FEED character. Output must contain exactly N such output lines and no other output lines.

A word contains only ASCII letters A through Z and a through z (convert upper case to lower case) and ASCII digits 0 through 9 and is not empty. All other characters separate words and are ignored except to notice word boundaries. Word boundaries only occur at the beginning and end of the file and at non-word characters. You may not assume a maximum length for the word, line, or input file.


He provides a tarball with sample implementations in C, Python, and Shell.

His C code is 183 lines long, Python 57, and Shell 11. The specs for this test seem particularly suited for shell.

I wrote a version in Haskell, commented and formatted approximately the same as his Python version, but using an algorithm more like the shell version. It comes in at 18 lines. Here it is:

import System.Environment
import Data.List
import Data.Char
custwords = filter (/= "") . lines . map (conv . toLower)
    where iswordchar x = isAlphaNum x && isAscii x
          conv x = if iswordchar x then x else '\n'
wordfreq = map (\x -> (head x, length x)) . group . sort
freqsort (w1, c1) (w2, c2) = if c1 == c2
                                 then compare w1 w2
                                 else compare c2 c1
showit (word, count) = show count ++ " " ++ word
main = do args - getArgs
          interact $ unlines . map showit . take (read . head $ args) .
                     sortBy freqsort . wordfreq . custwords

Taking a look at this, one thing that might strike you is the function composition in main. This takes the output from one function and feeds it into the next -- and the Haskell syntactic sugar for this makes it look a lot like pipes in the shell version. The interact call takes, as a parameter, a function that takes a string and returns a string. interact supplies stdin as the input and prints the output to stdout. Note that, since Haskell is lazily, this does not mean buffering up the entire input or output -- it is read and written on demand.

The rest of the functions are also standard in Haskell, and you can find them in the index to the library reference if you want to learn more.

I understand and agree that short code doesn't necessarily mean good code, but I think that Haskell provides a very elegant and expressive solution to many problems -- one that also happens to be remarkably concise.

Updated 9/4: Changed isLower to isAlphaNum to fix a bug, and removed unnecessary Data.Map import

Next.

Previous.