Stuff I have written/presented
Submitted by gwolf on Tue, 04/17/2007 - 14:03
First of all, sorry for the delay. Leaving just as the discussion gets started is bad, yes... But I'm only now reading Erich's and Sven's follow-ups. Both (as well as some comments in my blog) ask why not integrating the startup links in each of the packages - Well, basically because I don't think that most maintainers will take care to do this, and we will end up having a situation very close to what we have today: If I'm not interested in supporting your favorite init system in my packages, I just won't bother to make the scripts.
Note: I'm going into braindump mode. Verbose blabber and some stupidity might follow ;-)
Think on the webapp scene - Most webapps ship with an Apache-like snippet so that http://yourserver/thisapp just works(tm). I love that, and it's one of the little details that make Debian shine - Things usually work with the least administrator burden possible. But it happens that there are other web servers around there - They just become somehow second class citizens (I happen to sponsor/comaintain Cherokee, for instance), as nobody cares to include the equivalent snippets for them. Apache is the standard, and is good enough.
The same goes for sysv-rc: It just rules the world. Who will work all the needed patches to support all the different init systems? As the maintainer for a simple package which requires to be started up, I probably won't care to even understand all the intimacies of every init system, at least until they all have a decent user base. But by having one package per (server,init-scheme) pair, any maintainer can come up with the needed initialization.
Of course, this degrades quickly. First of all, as a user: if mydaemon is not correctly starting up, I will probably file bugs at mydaemon, not at mydaemon-initscheme. If mydaemon changes its parameters, we will witness transition of mydaemon-*.
Further, remember this is Debian, and volunteer-work has its downsides. If the mydaemon maintainer is a primadonna (or just does not give a flying crap about the runit init scheme), he will just trash reports regarding a nonimportant init scheme. Bad. And, as Erich points out, we have ~1000 packages including /etc/init.d/something - It will mean 3000 or so packages for a decent (not complete!) coverage of the different schemes. And, of course, a very uncoordinated way of working. But back to my line of thought: If I'm promoting an init scheme, I cannot just push it down each maintainer's throat. I must include at least the most important init scripts somewhere. Maybe we could just group daemons by task, and then have -say- a webservers-runit package providing the init scripts for each webserver for runit? This could cut down from 3000 to some 100 packages, most probably team-maintained... But it still faces many scalability problems, and the bug-filled-somewhere-else problem seems unavoidable.
I think something interesting could come off Sven's idea of providing several independent scripts instead of today's complete init scripts - This would make it easier to adapt startup/shutdown and similar events to different world views, and if not specifically needed, most init scripts could even be autogenerated calling the right bits here and there. That would rock - except in the corner cases (I predict no less than 10% of the packages will become corner cases ;-) ) where it will crumble apart. But maybe if a package declares it should be autostarted and provides the separate bits, the sysv-rc, upstart or runit helper can come up with an autobuilt initscript (or equivalent) - And if it does not work, it can always be overriden by a maintainer- (or user-) supplied, explicitly built script. Humh...
The topic surely calls for a Debcamp session, as Joachim says in comments in two of our posts and Erich acknowledges. Erich, as the main instigator of this blog series, I hope you can at least join via Ekiga or such, as it can be quite interesting - But, yes, none of the people involved so far participates in any of the inits' maintenance... Anyway, please keep the ideas flowing. I want to sketch something up, as I feel this can be useful - and not only for initscripts, but for many of the areas where Debian provides several ways to do the same thing. And, once again, that's one of the best points of Debian for me.
Submitted by gwolf on Thu, 04/12/2007 - 09:50
I was delighted at finding Erich's series of posts regarding init schemes - In fact, when reading the bottom of your third message I got disappointing at you stating that this concludes this series of blog posts. Maybe someone can follow up with some details on upstart (which seems to be the most promising init replacement)? - I expected you to delve a bit into other schemes, such as file-rc (which is, AFAIK, quite similar to the standard sysv-rc, but instead of having directories with symlinks has files describing each runlevel in similar terms, and I understand works in quite a similar logic to sysv-rc), runit seems to work in a way quite similar to BSD's RC...
I was particularly interested on your point of view on something like Init NG - And, of course, Upstart sounds sexy, and besides, being Scott's brainchild automatically stamps a must be good legend on it, at least for me. Shame that you didn't follow on with the series - but hey, nobody's paying you to do it ;-)
Anyway... I was thinking on a way we could get at least Debian maintainers work more easily towards having more than one init scheme for our daemons and such - or at least, shipping less cruft for derived distributions to clean up. Specifically, yes, our most notorious descendant goes Upstart, so /etc/init.d/* becomes crufty for them. So, what if:
Submitted by gwolf on Mon, 04/09/2007 - 10:31
Wow, what a wonderful weekend was this for Debian. And, yet again, I managed to miss the live announcement and party on IRC.
So... We got a shiny, new, French DPL. Just after that, we got one last release for Sarge, and right away we got a stable Etch - Who says having a new DPL cannot speed up things? ;-) Anyway... I don't remember where I started the meme when Sarge was released (it was not on my blog, it seems)... But here it goes again:
What were you doing at...
Etch release? Having a nice time with Nadezhda, walking around this broken and dear city in my last day of vacations.
Sarge release? At my psychologist. Yes, Sarge drove us all nuts.
Woody release? Sitting at a lent workstation at Departamento de Seguridad en Cómputo in my University. Of course, the announcement was broadcasted right away to everybody around me ;-) I was in NM by then, and was a bit disappointed because my work didn't appear in the release.
Potato release? Don't know... I was not yet involved with Debian by then.
[Update]: Thanks to Wouter, my old meme-starting message appeared - is he more patient than I am, or just more organized? :-) Anyway, boo for Jaws breaking old URLs (I upgraded 0.4->0.5->0.6->0.7 since then)
Submitted by gwolf on Sat, 04/07/2007 - 09:39
As I've posted before, I recently read Lawrence Rosen's Open Source Licensing Software Freedom and Intellectual Property Law. And I'm sure many of you will recognize the enormous constructive value of early-morning cavilations. Well, today I woke up thinking about strengths and weaknesses in th different Free Software licenses, and I decided to add my grain to the world of license proliferation. So, here goes version 3.14 of the CoPL. I wonder how long will it take before it reaches /usr/share/common-licenses on Debian systems ;-)
CONFUSING PUBLIC LICENSE ======================== This is version 3.14 of the Confusing Public License (referred to from now on as "CoPL"). Copyright (c) 2007 Transnational Republic. Additional copies of this license can be purchased at no cost from any Transnational Republic citizen at any of its recognized outposts, or freely copied. Any legal claims regarding Original works or any of their Standard versions licensed under the CoPL Should not abide by and be carried out according to the current law of the Transnational Republic. The Original author to pay for any attorney and other legal fees of any dispute regarding said Original author. This license text is designed to protect all the Technology covered under it under a thick layer of incomprehension. No technical, professional or social measures might be used to subvert the intent of this license. This license Must be carefully or professionally reviewed by a lawyer or attorney, under any jurisdiction. Any serious attempt to understand this license will immediatly terminate your rights to keep reading this license. Original works licensed under the CoPL will not be affected by this provision, you will still have permission to use them. Redistributions of source code Should not retain the above copyright notice, this list of conditions and the following disclaimer. 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this Confusing Public License. The Original work below refers to any such program or work or Standard version. 1. You desire to license the Technology to a large community to facilitate research, innovation and product development while maintaining compatibility of such products with the Technology as delivered by You 2. Original author desires to license the Technology from You on the terms and conditions specified in this License. 3. Redistributions in binary form Should not reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 4. The names "Joe", "Curly", "Moe" and "The Three Stooges Foundation" May be used to endorse or promote products derived from this Original work without prior written permission, as they are in no way related. 5. There is no number 5. Seriously. In all Original works licensed under the CoPL, all necessary technical and social steps May be taken not to include, in any explicit way, the number 5. 6. Original author Must make and give away verbatim copies of the source form of this Package without restriction, provided that Original Author duplicates all of the original copyright notices and associated disclaimers. 7. Original author Must apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version. 8. No Standard versions of the Original work Must be protected by this license. Original authors Should not choose a different, saner licensing model for the distribution of any modifications they make. The CoPL should be taken as a retroviral license. THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL YOU BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Definitions "You" means the original author of the work covered under the CoPL. "Original author" means you. "Thou" means God almighty. "May" means "Should not, no matter what". "Must" means "May". "Should not" means "Must". "Reasonable copying fee" means nothing. "Standard version" means a modified version of the Original work. DISCLAIMER The CoPL text, from the words "This is version" and up to and including this paragraph, is to be taken as a preamble, and will not be effective under any circumstances. All work licensed under the CoPL should be considered as licensed under the GNU General Public License version 2 or (at your option) any later version. It is not the task of this license to point you on where to get hold of said license.
Submitted by gwolf on Thu, 04/05/2007 - 15:26
I got a mail from the YAPC::Europe organizers telling me I won a book for registering early and sending in a submission (as I have previously told you). I was even more surprised to find out I am one out of two lucky winners! So my new book is Es lebe der Zentralfriedhof.
No news yet on whether my talk (Integrating Perl in a wider distribution: The Debian pkg-perl group) will be accepted... But this kind of incentive does push me towards attending even if I am not accepted - Of course, it depends on the University sending me there. But anyway, I'm a step closer to Vienna. Somebody wants to join over there?
Oh, and by the way: On my previous posting on this topic I linked to my conference proposal URL. Little did I know that this URL is private, accessible only to the Academic Committee and me. Yes, different from what I'm used to... but that's the way it works there.
Submitted by gwolf on Wed, 04/04/2007 - 22:59
Russell blogs about his new 22" cheap TFT monitor. You lucky bastard.
I use a 17" Dell LCD monitor at work (sorry, cannot recall the model), and I've been quite pleased with it. Granted, 1280x1024 isn't what I had gotten used to (1400x1050 on my previous laptop and previous work machine), but it does the trick - And for my current laptop, I went for a smaller machine, with a 12" wide-screen 1280x800 monitor. I still find the monitor somewhat small, and the missing 224 pixels _are_ noticeable - but the size is well worth it.
But what I've been playing at work with is changing the monitor orientation - This 17" Dell monitor can be set up vertically (1024x1280), and xrandr will merrily change the orientation. So far, I'm happy with this setup. I still feel there are some video-related quirks, and maybe the pixels are a bit off (i.e. black letters in a white background have a bit of a shadow), maybe it was visible as well in the regular configuration, but not as noticeable. But well, I feel it easier to work with for most of my work cases - For having a full-screen browser, each row is smaller and more rows fit on screen - It's quite pleasant. For doing Web development, having a horizontally split screen (one above of the other) between Emacs and the browser is quite natural. And when I use more than two frames (i.e. for following logfiles or debugging multi-factored breakages on servers ;-) ), well, they are small enough that it's similar to having the ol' regular layout.
I'd still like to get a second video card and monitor. I remember working that way in the job I left four years ago, and it was very comfortable.
BTW, Russell, for your needs I suggest you to try Ion. After all, who really needs to have a root window/background after all? :-)
Submitted by gwolf on Fri, 03/30/2007 - 19:01
It's been two weeks I got my latest toy. And, lets be honest - I don't buy me toys very often.
My very own espresso/capuccino maker! No, it's not a pro-level machine, nor does it try to be. I'm a bit disappointed as the espresso comes out slowly and homogeneous, with no foamy layer on top - But hey, it tastes great. So far, I'm still a terribly lousy capuccino maker, but perfection comes with practice.
Now, what's bad about this? First, that -although I'm a heavy coffee drinker, pouring at least 1 liter of regular filter-drip coffee down my throat every day- I very rarely drank coffee at home. Now I do. At least, two espressos every day - Well, two mugs of espresso, mind you - that's like six or so proper espressos. Yes, I'm trying to cut down on the coffee I get at work.
Second, well... Having the rich taste of an espresso in your mouth every day makes you despise and loathe filter-drip coffee. It just does not taste right anymore. The delicious roasty after-taste does not stay in your mouth for at least twenty minutes. But here is where the addiction part comes into play: I still need it, and when my work area's coffee machine is empty, I still go with my mug begging for coffee in other areas of the building.
Submitted by gwolf on Fri, 03/30/2007 - 09:24
And, while on my way there, I'll get to visit my family in New York (and get to know a bit of the city, I hope) for a couple of days as well! :D Leaving Mexico in June 7th, three days in NY, travel to Edinburgh on June 10th (arriving early on the 11th), and head back home on the 24th. Yay! BTW, attempting to save some money and the pollution caused by air travel, I asked Google for how to drive from New York to Edinburgh. It looks clear and easy, but in the end I settled for air travel. Specially for the estimated travel time (about 29 days 17 hours)... Oh, and item 23 slightly worries me: Swim across the Atlantic Ocean: 3,462 mi.
Submitted by gwolf on Tue, 03/27/2007 - 17:17
As I have stated here long ago, I do not really believe in the Debian Project Leader. Yes, it has an importance. Yes, it's not merely a decoration figure. But I do doubt it can really make much of a difference. I don't hold exactly the point of view I held back then, but it's still quite close ;-) Anyway...
[ 1 ] Choice 1: Wouter Verhelst [ 7 ] Choice 2: Aigars Mahinovs [ 3 ] Choice 3: Gustavo Franco [ 2 ] Choice 4: Sam Hocevar [ 4 ] Choice 5: Steve McIntyre [ 4 ] Choice 6: Raphaël Hertzog [ 5 ] Choice 7: Anthony Towns [ 3 ] Choice 8: Simon Richter [ 6 ] Choice 9: None Of The AboveAs it's not a post I strongly believe in, with that many proposals in play, I cannot say I thoroughly reviewed each of the platforms/rebuttals/debate (I did follow them all, of course). I agree with most of what most of them propose (Sorry, Aigars, but I don't agree with you a bit ;-) ). One thing is, yes, worth noting: During the dunc-tank brouhaha, I spoke very little, but was mostly supportive of AJ's pushing a real new proposal. Why am I ranking lowish AJ, Raphaël and Steve (who were, after all, in there)? Because I did really appreciate AJ having the guts of pushing, of being brave enough to go into uncalm territories trying to change Debian. Is that the change I want? No, I don't really think so, so I'm not voting him (or Steve, as the 2IC, or Raphaël, as one of the board members) very high. And yes, one of the reasons I'm ranking Wouter first is his tendency not to be too passionate in flamefests. And, of course, not having much of a platform - Having an overly ambitious platform which would change the conception of Debian both towards the inside and towards the outside is completely unrealistic. And that's one of Aigars' cardinal sins :)
Submitted by gwolf on Wed, 03/21/2007 - 20:21
I run my blog using Jaws, a simple and quite nice blog-minded CMS project started by several friends of mine. I've long wanted to contribute to the project, but so far, I've only reported a couple of bugs. Boo for me! ;-) Anyway, I just updated from 0.6.2 to the just-released 0.7.1. Guys: You rock! What a painless, easy and (so far) well-working update! I am late already, so I'm not going to check into all the new features. So far, I'm quite happy with the extra easiness and control to get some comment-spam protection, my main gripe so far. I hope not to flood any of the Planets with a RSS upgrade (it's not been a problem lately, I guess that the Planet guys fixed that as well ;-) )
Submitted by gwolf on Mon, 03/19/2007 - 18:19
Uwe asks about fast, reliable, not noisy storage mechanisms - And yes, of course, he talks about Flash memory's well known limitation: The relatively low number of write cycles each area of the memory is known to be able to withstand. I recently told this same argument to a friend who was enthusiastically telling me about his dream project of setting up a computer based exclusively on solid-state storage. Of course, he didn't like the limitation. But after reading a bit (sorry, I don't have the URLs at hand - but Google is a good friend), it seems that many (most? all?) controllers work around this limitation by rearranging the most used blocks around, so that the Flash gets as evenly used as possible. Quoting from Wikipedia's article on Flash memory:
Another limitation is that flash memory has a finite number of erase-write cycles (most commercially available flash products are guaranteed to withstand 1 million programming cycles). This effect is partially offset by some chip firmware or file system drivers by counting the writes and dynamically remapping the blocks in order to spread the write operations between the sectors. This technique is called wear levelling. Another mechanism is to perform write verification and remapping to spare sectors in case of write failure, which is named bad block management (BBM).So, Uwe, just check the media you get supports wear levelling technology, and you should be safe.
Submitted by gwolf on Thu, 03/15/2007 - 17:04
Ben, Erich and Russell bit - Why shouldn't I?
A. Copy the list below to your own journal and Bold the actions you are already taking Underline the actions you plan to start taking Italicize the actions that don't apply to you B. Add one (or more) suggested action(s) of your own C. Leave a comment here, so that she can track the meme to your journal, and copy your suggested action(s) back to my master list. Shame - I cannot comment on this, as I'm no a LiveJournal registered user. And I don't intend to be either.
Submitted by gwolf on Tue, 03/13/2007 - 19:44
[ Warning: Long post follows ] Just today, I read that H01ger is happy he can wear just a T-shirt somewhere in Northern Germany. Well, from my point of view, much the opposite has happened. And I'm not just happy - I'm fucking proud! About four years ago, Nadezhda went almost every weekend to hike to the mountains with the Grupo de los Cien people. I'll sidetrack a bit to speak about them: Grupo de los Cien is a group of mountain lovers (no relation with the enviromentalist group which later took the same name) that, since the 1950s, have built and maintained the high mountain shelters in Central Mexico. It is a group, by the way, with which Nadezhda fell completely in love - and now it's up to me to find out why ;-) But lets go back to the main topic. Almost every week, she came back delighted and loaded of energy from a mountain hike. Almost every week, I told her I wished to go with her, of course, if they went to a simpler route. Of course, lugging around over 130Kg of humanity is no easy deal. And, after over a year and because of many problems that came together at once, she stopped going to the mountain as well. She always kept an eye on their friends, but so far had not been able to return to the mountain. Ok, so last week she heard the group was organizing volunteers to go fix the Ayoloco 2 shelter. She signed up, and invited me. I was afraid, but accepted the challenge - Of course, full of fear. Being this a historical event (at least in my life), I cannot but offer you some of the photos I took. And, yes, I've just started playing with Flickr. Lets see if it works for me ;-) Saturday, 5 AM, we woke up. 5:50AM, we met part of the group near Daniel's house, in Condesa. 7 AM, we were having a nice breakfast (tamales and coffee, yum!) in Amecameca, still 28km from La Joya. From Amecameca, we went to Paso de Cortés, where we met the rest of the group, and from there we went by a little, bumpy and unpaved road until La Joya. Somewhat around 20 people started the hike at around 9 AM. According to Google Earth, La Joya (just South of the Iztaccíhuatl - white woman or sleeping woman in Náhuatl) is at 3995m - And, of course, to start at that altitude is not easy. The air is very thin, and walking a little bit too fast quickly makes you feel the blood pumping, trying to get some more oxygen. I often remembered how my Bolivian friends behave in Potosí, walking slowly even when in a hurry :) We first went down a little valley, then up. The first portion of the hike was on soft, wet sand, with some grass (what we call zacate - Strong, hard grass, not what you commonly see in a garden). I soon learnt that was a blessing, as it was by far the easiest part. Then we went up a steep and quite rocky area - It started getting tricky for somebody not used to trusting his own feet. And it was steep, yes. This was the first time (of many, of course) I started thinking whether I should head back. We reached what I foolishly thought was the summit, only to find a steeper, longer way to go. It started getting common to find little deposits of snow/ice (I don't know the exact term in English - it's called aguanieve in Spanish, literally snow-water. [[Update]: Thanks to the now-DD H01ger, I now know that aguanieve in English is called sleet]. I understand it's a bit harder than snow, but still much lighter than hail). We crossed a completely rocky section - No sand to hold the rocks to their place. That meant being extra careful (and thus, extra slow). But just afterwards, in case it was not enough, Mother Nature answered my pleads for some sand - we crossed a section made exclusively of loose sand. And, please, if you have ever walked upwards on sand, imagine doing so at over 4000 meters. I was taking so much care of how and where I stepped that I strayed not more than 5 meters down of the path the group was following - Being able to climb back to the right path was really not easy. This was the point that not only I was thinking about heading back, but I'm sure Nadezhda thought I would abort the mission. She cheered me up, took some pictures of me as soon as I got out of the sand trap, and we were able to move on. After the sand, some more rocks, and we started feeling the chilly wind. We entered a cloudy region - Humidity does get the coldness into your bones! We could not really see where was the rest of the group, so we proceeded the best way we could. Fortunately for Nadezhda and me, just behind us came the very experienced Mario Corsalini and led us. And, yes, we finally saw the Ayoloco 2 shelter. I was by then exhausted, after some four hours of ascent. I ate one of my apples - The sweetest apple I have tasted so far. After resting a bit, and realizing I was almost frozen (we were at 2 Celsius under, with constant chilly, humid wind)... Then I started working with the guys, reinforcing the shelter, while Nadezhda and some other people painted the inside with. People started eating - of course, I joined them. And, after some time up there, we started going back down. Miguel Ángel, a volunteer in the Izta-Popo park, walked a good portion of the descent with me, giving me tons of help and tips. Thank you, thank you, really. The descent is, of course, much easier - We were chatting most of the time, and we made only around two hours back. The weather was quite nice on us - We had some aguanieve falling every now and then (yes! Yes! many of you guys have heard/read me bitch on how I had never seen snow falling before - Ok, this is not exactly snow, but I think it qualifies as my first experience ;-) ), but aguanieve does not make you wet, as it bounces off the clothes. When we approached La Joya we started having some light rain. We hopped in the cars, and then the rain really began. But even if this was not enough: Grupo de los Cien was celebrating the 83th birthday of one of its senior members, Poncho Rico. No, being 83 years old is not an excuse for skipping this memorable hike. We went to Anatolio's house, very close to Amecameca, and had a delicious dinner, cake and drinks. Nadezhda: Thank you. So, so, so very much. Thank you for being so patient with me, for dragging me up the Sleeping Woman. Thank you for getting me into this so very important and beautiful experience. I hope this will be the first of many. There is still a very long way for me to go before I'm really up to the challenge, but believe me: This will not be my last time on the mighty mountains.
Submitted by gwolf on Tue, 03/13/2007 - 11:17
Eddy Petrisor wrote quite an interesting text about the shortcomings of the .deb packaging format, specially comparing it to Gentoo's ebuilds. And, basically, it all comes down to this phrase:
Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make fileNow... Is debian/rules really expected to be a makefile, or it is just customary for it to be so? Look at the very top of your rules files - you will see they (at least, almost) always start with #!/usr/bin/make -f - That means, of course, that you can omit the fact they are makefiles. While packaging/debugging, I often run -say- fakeroot debian/rules build && fakeroot debian/rules clean. That, my friend, is closer to the invocation you often use for a shell script than for a makefile. I don't know if we have tools that rely on having rules called via make (and that should be easy to correct if needed), but I really don't see it problematic at a first glance to create packages based on something different than a makefile. Recently, I've been tempted by CDBS. I still don't fully understand its flow, and it's still mostly a dark-magic beast for me, but at least I am comfortable using it for my everyday packaging work (hey, pkg-perl group, I'll be bugging you again with my weird ideas soon ;-) ), but it surely has the advantages you quote in your message: It takes part of the complexity away. Of course, it introduces some extra bits. By using CDBS, the packaging entry level is considerably lowered - but the real understanding of properly maintaining a package becomes somewhat more difficult. Or is it just me clinging to the comfort of having learned my way around writing debian/rules?
Submitted by gwolf on Mon, 03/12/2007 - 13:14
Due to the extreme stupidity of the bank that holds my money whenever I have some, we were unable to pay my main domain name (gwolf.org) together with two others - I mean, the fscking bank mixed up the secret questions/answers, and we were unable to confirm our identity in order to pay to my favorite registrar (do you know they sponsor Debconf? I've been their customer for at least five years, and they rock). As of this Sunday, gwolf.org went off the net. Of course, being it a sunday, it was impossible to get a human in the right area of the bank. I must really thank Nadezhda: Despite being quite busy today, and after spending a couple of frustrating hours Sunday night trying to reach somebody, she managed to take the needed steps. Our domains are back to life. If you sent me a mail during this weekend, please send it again.
Talks, papers and documents by category
Blog posts by category