Debian

On the Debian Maintainers GR

Submitted by gwolf on Mon, 07/30/2007 - 12:06
Hmh... It's hard to get to a decision on this aspect, although I'm mostly sure I'll vote for a "yes". I have read most posts on this subject on debian-vote and on the planet, and I'm still not too much at ease... Anyway, one of the most relevants so far is Joerg's - And not because he is so involved with the NM process, but because he drives me to what I think is a very important point few people have addressed:
For long, we have been saying that you don't have to be a programmer to help Debian - But so far, we have been unable to deliver except for this funny French guy. And although the current proposal still focuses on getting a step closer to DDness, and for many people this seems like geared at reducing the frustration when going over the NM process, my impression is that this will help us implement something similar for other areas.
Some people have complained about implementing decisions per policy instead of doing so gradually. Thing is, I feel, this kind of proposals have been reiterated over the years - and they have always dropped into the silence because some actions need to be taken by the people who are less willing to. Maybe the only way to break the inertia is to take a step by a GR vote. Maybe parts of it will have to be undone or re-done differently if we end up with the wrong results - but we will have broken the status-quo. Maybe, who knows, this will serve as an experiment - and after another long series of long flame threads we will end up in 2010 in the same position are we currently at - but it won't be because of inaction.
( categories: )

On collaborative maintenance

Submitted by gwolf on Sat, 07/14/2007 - 00:07
Following Zack's and Lucas' posts regarding group maintenance of packages: Do I have to AOL with you guys? Yes, I also agree with Zack's both 1 and 2. And I also want to share the bit of experience we have got in this regard in the pkg-perl group. In our case, group maintainership has often saved our collective butts. We have also debated somewhat which way should our packages' maintainership be handled. In the end, our packages' maintainer will (most usually) be the pkg-perl group itself, subscribed through an alias that reaches all of us. Then, every group member that feels identified with the package lists himself as an uploader (note that this does not necessarily have a relation with the last uploads, at least not as strongly as in what the KDE and Gnome groups do, according to Lucas' post - it's closer to the pkg-ruby-extras handling). Of course, there are some packages which I have NMUed in the group's pool - packages I prefer not to have listed in my maintainer page, as I don't usually care too much about them, but I happened to be able to fix a bug with them.
Now, what about the roles of the different group members? Each of us has some skills that make him better for part of the task - i.e., we have an amazingly knowledgeable member, Niko Tyni. He just fixes all the bugs that baffle us. Honest, my best kudos to Niko, he is a good part of our team's success. And then, we have hard-working people as Gregor Hermann, who not only fixes also nice amounts of bugs, but also writes and runs general QA tests throughout our over 300 modules. Neither of them is a DD yet. And of course, many other hard-working folks. Some of us are DDs and try to upload promptly - and, of course, also try fixing bugs. So far, we are in good shape, and we tend not to lag too much. I have taken some vacation periods (both announced and unannounced - sorry :) ), but to my surprise and amazement, my packages tend not to be buggy - Why? Because there is a real team looking after them, and in the end, we keep an eye on each other.
For the pkg-perl group, group maintenance has really worked. We collectively maintain more packages than it would be reasonable for all of us added together as individuals, and they are in a better shape. There are several things we can make better, and we do try to address them - it is not yet heaven, but... :) I'll elaborate later, when I finish a text I'm preparing for presenting at YAPC (it's not that long, of course - During Debconf, I showed advances of it to several people... I just have left it aside). Right now... Well, I have 3hr of sleep left before we leave for a daytrip to the beautiful (but hot and humid!) Veracruz Huasteca. See you on Sunday/Monday!
( categories: )

Celebrated 10 years of the SC

Submitted by gwolf on Fri, 07/06/2007 - 06:08
Following Liw's initiative, yesterday night Nadezhda and me joined the distributed pancake party. With a nearby restaurant's hotcakes, anyway, not as fresh or as great as they could, but you can still smell the spirit:

(artwork by Nadezhda)
And... Well, it was not until this morning that I checked on the Wiki just to discover that Damog took part of the same distributed party, just ~15km away from us. Shame - I had just met Damog that very morning at the University :)
( categories: )

Back from DebConf7

Submitted by gwolf on Mon, 06/25/2007 - 11:43
Ok, I'm officially back. Yup, when you have a meeting just over your regular lunch time and are suddenly seen as the guy who will fix the institute's video needs just because you worked manning cameras with the amazing DC7 video team, it just means you are back home. Lets see how several projects that have sprang up in the last couple of weeks (both at DebConf and at work) start materializing.
Anyway... DebConf was great. Just great. This time I had time both to feel I was useful and productive (mainly doing video-related stuff, although on some other points as well), to attend several interesting talks (although manning the camera did not leave my attention as complete as I would have liked), to have several nice chats, to play a good couple of hands of Mao - Hell, thanks to Kitty, I managed even to have some chats _while_ having a hand of Mao!
Of course, I was not productive neither with my Real Life duties nor with with the Debian stuff I wanted to hack on - In fact, the most productive period during the two and a half weeks I was away (excluding probably the two days I spent understanding/hacking Pentabarf with Damián) was the flight back - During the ~12hr we were on the air, I managed to read the second half of my book, to review two chapters for a thesis, to write a (really simple) article and to work on another one.
Anyway... Thanks to everybody. I had a great time, and am only looking forward towards Argentina.
Ah, and I also got The Debconf Flu.
( categories: )

Fun at Debconf - And redefining targets

Submitted by gwolf on Tue, 06/19/2007 - 05:06
For some days at Debconf, I've been somewhat stressed and frustrated. You see, the first DebCamp/DebConf I took part in (Oslo), I was really productive - Besides meeting lots and lots of people and having a great time, during DebConf3 I learnt a scary lot about the project in many aspects and, although I was already a DD, it really decided me to get more involved.
When we were at Brazil, I had a great time as well, but (code-wise, bugs-wise and so on) I was much less productive - I started peeking at the processes that involve running such a strange and intensive conference, I was more active talking with other Latin Americans, and so on.
So, for DebConf5, I was a full orga team member - Man, did that make me feel powerful! Of course, as there was so much orga work to be done, I basically didn't hack into anything. During the day it was organizational work, and during the night time-after-22:00 (how do you people live without a night!?) it was sauna. What a great invention of the Finns! After getting relaxed by sauna, nights were socially intensive
About DebConf 6... Well, it was hectic and chaotic. It is probably the most stressful two-week period (two week? Two months at least! Well, anyway) period of my life. It is the only Debconf so far I don't even remember having had much social interaction. But still, for reasons I fail to understand, I am really happy we held DebConf in Mexico. It is one of the best, most exciting and (hopefully!) unrepeatable experiences in life.
What about this year? Well, I took a couple of steps back, and while I'm formally still part of the always-great orga team, there are way too many things I don't know or can answer. Partially, I blame that impossible dialect of English they speak in the UK - Please, next time you feel a bit tired, lock yourself in a room with six hurried English and Scottish people, add a couple of Germans to the mix (no, I don't have problem with the other accents spoken in there), and try to get the general lines discussed. Impossible.
As I took a couple of steps back, I thought I would be able to hack a bit. There were some great ideas of things to work on - But so far, I've practically not started with any! I wanted to do some QA rounds in the pkg-perl repository, kill a couple of long-standing bugs, and then there is thismetainit idea we have been discussing... So we held the MetaInit BoF, and Nomeata has been actively hacking it - But I must recognize I have done little besides documenting and cleaning a bit a minor module of it. The second day I was here, I started working on something that was completely outside of my plan (hacking up a subsystem for Pentabarf to help the video team, as I previously complained). Just after we finished with it, DebConf properly started - So I've been basically taping the talks, reviewing the files, in the orga and video meetings... Until yesterday, I was quite frustrated not to have been able to work a bit on the couple of things I wanted to do. I have not yet been able even to work on three things I need for my Real Life, which still counts, even at DebConf.
But then, yesterday I read a post by Wouter - Man, you are completely right, and I must keep this in mind at all times: DebCamp to me isn't about being productive, so much as it is about meeting people and getting to know the environment. Well, I've terribly even failed to get to know the environment (I'll reserve some time on Thursday or Friday, I hope), but so far this has been quite fun, and completely out of what I usually do. And, even without me considering this, DebConf has been quite productive for me in ways I didn't expect - I've met and had a couple of beers with the pkg-perl group (and today I'll meet with the pkg-ruby-extras group), have plotted several things with the Spanish-Speaking group (which, by the way, has tremendously grown since we were at Oslo), I even started hacking a bit my way into Pentabarf, which will be very useful once I get back to work!
Anyway, in short: Wouter, you made me reconsider, you made my day - Thanks! And now, I'm a happy man again :)
( categories: )

Momomoto!

Submitted by gwolf on Thu, 06/14/2007 - 11:31
Yesterday and today, I've spent most of the time sitting next to Damián Viano (des), feeling 1337 because we are doing exactly the heavily recommended pair-programming thingy with a Rails application that everybody in Debconf is familiar with: We are adding some stuff for our beloved video-team in Pentabarf! Now, Pentabarf is -as we were trying to explain earlier on, amidst angst and frustration- a strange beast: It looks like your regular Rails app. It smells like Rails. But it tastes like Java.
For some reason, the Pentabarf author (who I sincerely expect to meet soon - yes, he is coming to Debconf as well!) decided not to use Rails' killer app part, the one which has got most interested people into the whole framework, ActiveRecord. For all of the object-relation mapping needs, uses something called Momomoto.
To its defence, Momomoto is a lightweight library. This has the great advantage that, although it completely lacks documentation, its source code is very easy to follow, and it takes just a couple of hours (and forehead-wall bangs) - Much unlike ActiveRecord. But on the down side, as lightweight as the library is, the model it uses is completely suboptimal for many of our (so far really simple) uses. We have a simple view, for example, that runs in at least On^3 (measured in independent DB queries, of course). Going through a different model, it could at least be cut to a much nicer On^2.
Anyway... I'm relieved. The extension the video guys wanted is not that large, and it's mostly done. It is surely showable by tonight's meeting (modulo a couple missing bits, of course, but it's just bits), and will be ready no matter what by tomorrow. I'm just sorry I had to throw des aside, as pair-programming for two days in a row for the best portion of the day is not good for sanity.
Well, neither coming to Debconf is, so whattheheck... ;-) At least I could get a bit of my mail and RL work backlog processed.
( categories: )

Arrived!

Submitted by gwolf on Mon, 06/11/2007 - 08:11
Ok, so here am I, just arrived to Debconf, surrounded by tens -soon to be hundreds- of Debianers. A big YAY! :D
( categories: )

On magazines without editorial direction

Submitted by gwolf on Wed, 05/16/2007 - 14:45
Scott complains on how Linux Format #93's articles comparing Ubuntu and other distributions often contradict each other, and blames it on the lack of any editorial direction or basic research.
I... Have to confirm this. But anyway, I can stand a bit on the different writers' side - Each article is written by a different person and, although the magazine must try to be coherent (of course, within certain limits - if the magazine suggests editor's picks in one article, they should not bash them to death in the next one).
I write the Linux column in the Spanish edition of PC Magazine. No, it's by far not a technical column, nor anything far like it. The magazine is end-user oriented, and clearly sponsorship-driven - In fact, my column was not part of the magazine for quite some time, as they gear it towards end-users, and sponsors (I cannot venture which sponsors, but your imagination will probably go to the same company as mine) do not like what I write about. All in all, I get the general topics which each month's edition will cover, and I just have to write an article about one of them. Of course, I don't know most of the other writers. There is no interaction at all.
And I guess that Linux Format is a typical magazine - If they run like PC Magazine, they just won't have the time to put all the articles together checking for inconsistencies. I think it is enough of a task to chase the contributors month after month (BTW, I'm a week late already :-/ But I cannot finish just today, as there's too much work to do, and I spend my time blogging... Hmh, time to finish this post, as coitus interruptus as it may seem).
( categories: )

Starting as a mentor soon

Submitted by gwolf on Wed, 05/16/2007 - 11:04
After a long time talking this as a mere potential would-be-nice thing, finally we are putting some action behind our words: One week from now, Sergio Mendoza and I will start a ~2 month long extracurricular course on Debian. The students? We have 12 students of the Facultad de Ciencias at my University. The students are pre- and post-graduate (licenciatura and maestría), from the Phsyics and Astronomy areas. Sergio got this group as he is a teacher and researcher at Instituto de Astronomía.
While this first iteration is completely extra-curricular, unofficial and by invitation only, we expect this pilot course to be later presented as an official course in the Faculty.
Many people will remember I usually don't like general courses on Unix, Debian or whatever. What made me accept this time - even more, be enthusiastic about it? First of all, the requirements: We assume the students already know their way (at least as users) in a multiuser Unix-like system, so we won't be hand-holding them all the way through. Second, the focus: Sergio (who is among the first Debian users in Mexico and who got us our first full Debian mirror - which is actually a bit sick, but awaiting for prompt hardware upgrade ;-) ) wants them to focus on becoming developers. Not only developing science-oriented applications and libraries, but properly packaging and integrating them in Debian (and, hopefully, some of them will become interested in joining the project). We will also spend a good portion of the course on teaching them good practices on system adminsitration, teaching the principles behind what we do (i.e. I'm looking forward to participating, and in this case as one of the more students, in the sessions where different cryptography-related topics will be explained, starting from their mathematical foundations and going all the way up towards the implementation, where I'm more comfortable at).
It will be a nice experiment. I will be away for at least five of the lessons (Blame Debconf!), but I'm really looking towards the process and the results.
We will be making rough documentation of what we teach. We don't have a planned complete program, as we want to go with the group's real skills and interests, planning not more than three lessons ahead. This will be, however unofficial it is, my first time in front of a group in a university-esque setting (i.e. not short sessions, not capacitation built for a company, but with people eager to learn what we want to teach. I'll post again on this topic :)
( categories: )

On certifications

Submitted by gwolf on Thu, 05/03/2007 - 12:33
Ok, so LPI will be at Debconf, giving discounted certifications to registered attendees. Is this good or bad? Mario likes the idea, Madduck is in the middle ground, not decided on his stance on this regard, and Joerg basically says it's not worth much to him personally. Actually, I'll quote Madduck, as he has an interesting point:
I am not looking for employment, and if I was, I'd certainly not want to work at a company that thinks certifications are the true proof of capabilities. So I guess that leaves me with a 'no' still.
When confronted with this topic, I always oppose certifications. Why? First of all, I think they are worth very little. I got three or four Brainbench certifications when they were free - And of course, noticed right away that such a simplistic test is worth very little. Of course, LPI is a better established name, and is usually respected - Lets be fair, and talk about LPI together in the line with Cisco's, Microsoft's, Novell's and similar certification programs.
I've worked with several people who have got certified in different technologies, and almost always, this works against them rather than in their favor - Such people usually are blinded to all but their technologies. My most recent experiences are with the network infrastructure people - Cisco people know how to push Cisco, but know very little about protocol details, and cannot recommend a tool that's not madesold by Cisco. Same goes for 3Com. Same goes for everybody else.
Although many certification tests include general situations like Solve this real-world problem, they are hampered by the final exam syndrome: The certification candidate spent a couple of nights frantically reading the books, and the material sits eager to jump on his brain lobes. Of course, given a couple of weeks, he has forgotten most of it and confused the rest. No, I don't have hard data to back this up except for my experience - But I have some experience at least. Oh, and of course: This people can quote from memory in inverse alphabetical order each of the command-line options to ls, but might be unable to spit up a clever shell pipeline without sketching it in paper and thinking it over for some minutes.
What will this mean for most of Debconf's target audience? Well, just what Ganneff and Madduck said: Take the test if you want to get a new job more easily - but you should have more confidence in yourself.
Just as a final note: Whenever I've interviewed people to work with me or for people that trust me, from all of the received curricula, I start by throwing out every curriculum that has the certifications earned in a prominent place. People who give too much weight to certifications IMHO tends to be worthless to work with.
( categories: )

tbm's Release Management talk

Submitted by gwolf on Wed, 04/25/2007 - 19:09
Thanks to Romain Francoise, I found and watched Martin Michlmayr's Release Management in Large Free Software Projects talk on Google Video's Open Source Speaker series. Martin: Thanks a lot, great talk. I've been following your presentations lately, as I've given some talks on this topic - Quality Assurance on Free Software Projects (Spanish only) - However hard I try to remain faithful to the subject, I end up giving a talk on what Free Software is and how its processes are naturally more prone to yielding better quality than propietary projects.
Anyhow, with this post I want to do basically three things:
  • To cheer Martin for writing and presenting the topic. I've been refering to your work for a long time, and although my presentations are not formally papers and thus have no quotation value (in fact, they often don't have the references as anything more than comments in the source files, it at all), I should thank you frontally and publicly.
  • To get some more attention to the topics presented. Your point is very interesting and important to be taken into account specifically for Debian: I'm not 100% with you regarding that time-based releases is the way to go, but the point you make when discussing GCC (IMHO) is an important one: A project can shift to time-based releases even if it does not release on time, and its general inner processes can become quite cleaner. I do think we witnessed this with Etch in Debian - The process was much more believable and peaceful (even with all the release-related mudfights) than with Sarge. I think it partly stems from what you point out: We aimed to release in December, and we failed to precisely meet the target - but having the date helped set the release goals to something believable, and not let Sid's unstability drift too far away. During Sarge's testing cycle, for a long time, few of us even cared to use testing at all, as it was... Something completely undefined.
  • To get some insight on some points. Martin, in several of the projects you analyzed, there is a tendency to get to a six months release cycle. Many other projects also follow that cycle - There is a time-based project you didn't mention that is to me one of the inspirations of such model, and has proven to work for over a decade: OpenBSD. Yes, it lacks in many areas, and definitively not everybody can aspire to become an OBSD developer, but they have done high-quality six-month releases since they exist. However, speaking specifically for Debian: Would you like our project to follow such a schedule? For many reasons (including one you mentioned, the difficulty to support several concurrent versions, or just having oldstable versions be left too early with no support) I think we should aim for a 18 month cycle, 12 at the very least. Either I lacked attention when you went over that part or you didn't mention it - but why do you think such a short cycle is good for so many projects? What would you like Debian to do? (Of course, for answering this, you might be Martin, or somebody else entirely ;-) )
( categories: )

Init-related ideas BoF submitted for Debcamp

Submitted by gwolf on Tue, 04/17/2007 - 17:27
Ok, so it just seems like a hot topic - I just submitted a BoF for Debcamp to talk about the init-related ideas we've been discussing. As Debconf's Pentabarf conference management system does not like disclosing talk details before the talks are accepted, I'll reproduce here my short blurb:
This BoF comes out from several ideas posted in Planet Debian by Erich Schubert, Sven Müller, Joachim Breitner, Mike Homey and myself (so far). It's not to be "chaired" by any of us particularly, but I expect an interesting brainstorming session.
There are several different init systems present in Debian - However, we are only supporting currently one of them, good ol' sysv-rc - We have close to a thousand packages providing init scripts suitable for it, and close to none for all of the other systems.
In current systems, full of hot-pluggable devices, changing network configurations and so on, however, I think this situation is quite prone to change - sysv-rc and its runlevels are better suited for stable server-like systems, and is hard to adapt for future needs.
We will talk about the potential difficulties Debian will face in order to better support more init schemes, and discuss some ideas to solve them.
This should be a brainstorming session, not much material will be prepared (maybe some sketches by each of us, but nothing formal). If you plan on attending, take a look at the messages linked to in the 'links' section.
Note that, following Nomeata's suggestion, I'm presenting this for Debcamp - If you are not attending Debcamp and are interested, we will try to set this up via some sort of videoconferencing (or at least the usual video feed + IRC feedback), and I do hope we can have something showable (at least a broken concept) after Debconf.
In not-so-closely-related topics, I just learnt there is a shadow of doubt regarding my presence in Edinburgh - I will do my best to dispell the threat. I just don't want to miss a Debconf!
( categories: )

Init followup

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.

On system init schemes

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:
  • All daemon-like packages (i.e. those containing a daemon, or running something at startup, i.e. setting up a service interface) will be affected. Lets call our sample daemon-bearing package example
  • example will no longer ship an initscript. In fact, after some time, policy will mandate no initscripts (that is, what we today put in /etc/init.d) are included in our base packages. example will only recommend example-init. Why recommend it? Because it does not even now depend on a specific initscript - I've rolled some systems which are based on my very own init handler, for specific needs.
  • The original example package maintainer will probably take his very same initscript, and package it as example-sysvinit. This script will provide the example-init virtual package. (Of course, this will mean a very real proliferation of virtual package names). example-sysvinit will depend on sysv-rc.
  • The same maintainer, or a different one, will also package example-nginit, example-bsdinit, example-runitinit and/or example-upstartinit, depending on their respective infrastructures, and providing as well example-init. Ideally, they won't even have to conflict on each other.
  • Maybe I'm daydreaming and this could just be a bit too much... But with all support in place, even the init system itself could be handled via /etc/alternatives ;-)
This means, yes, a serious explosion of very small packages. But it also means less dependency on a specific maintainer to be sympathetic to yet-another-init-scheme. If I'm pushing superb-init, which does preemptive reverse dependency tracking and invention and works based on the oh-so-3v1l aptsh, and I'm having a hard time convincing anybody to update their packages to support my init scheme before it matures, I can at least come up with all the needed scripts to get my system usable and considerable for the masses. Sounds decent? Did I smoke too much crack? No, I haven't had my morning coffee yet, so I'll go grab some while this hits the planet.
( categories: )

Etch is done! Sarge is done once again! Sam rules! Yay for the weekend!

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)
( categories: )
Syndicate content