There was a discussion today on the LUV-main mailing list about apache virtual hosting. Someone suggested mod_vhost_alias which is OK for a simple solution, but pretty limited. IMO, there are much better ways of doing it. Specifically, generating config fragments for each virtual host. I wrote such a system years ago, and have always thought “I should package it up for debian”. There’s a moderate amount of work involved in doing so, and probably an even larger amount of support work afterwards. Worst of all, I’d have to write - or con someone else into writing - documentation for it (it’s easy enough to use that you can be SHOWN how to use it in 10 minutes, but that isn’t good enough for a distributed package). I guess the point of this blog post is to find out if there’s sufficient interest to make it worth the effort. Feel free to comment or email me about it. If anyone wants to look at the code, i can tar it up easily enough, and even write some simple/minimalist instructions. anyway, here’s (a slightly edited version of) what i posted to LUV-main: Preamble I looked into apache’s mod_vhost stuff years ago, but IMO it’s just too inflexible and limited to be of much use. It’s fine if ALL your vhosts are identical…but not if you need different settings on some or all of them. As soon as you need a custom setting for one vhost, you have to step outside mod_vhost_alias and roll-your-own anyway. which means you now have two different methods of configuring your vhosts. Instead, I’ve used my own vhosting system for years (long before mod_vhost), on dozens of servers…the largest of which had over 500 vhosts on it - the biggest problem was the enormous number of file handles the apache processes needed for log files. After tweaking the kernel file-max etc limits, it actually worked without problem but I always intended to rewrite that bit of it to use a log splitter daemon, perhaps vlogger or similar. Unfortunately, I a) left that job before I had time to implement it, and b) never did figure out a good way to handle the error logs because apache doesn’t prefix the vhost name to ErrorLog output like it does for CustomLog outout (best compromise was to just have one combined error log rather than one per vhost….most web programmers/website operators never look at the error logs anyway. Personally, I find it invaluable, most people don’t even seem to think of looking at it) Synopsis of Operation 1. Creating a new vhost is a 3-step operation:

1. create a user (with adduser), optionally with a postgres or mysql account of the same name.
2. edit /etc/virtuals/virtual-hosts.conf, copy/paste/edit one line
3. run “make”

In step 2, hardly anything needs to be changed from one vhost to another - in the most common case, just the account’s login name, and the domain name. There are a number of different “flags” that can be set for each vhost in this file - ssl, cgi, mason, htdig, webcheck, aliases, group, samba, canonify (use mod_rewrite to redirect back to the site’s canonical name), and more. The Makefile runs perl scripts to generate the apache config fragment (and other config fragments - e.g. for htdig and samba), add/remove any IP addresses if needed (usually not, with name-based vhosts), set up the home directory structure, copy in any sample files (e.g. html forms and images for htdig), and reloads apache. It also checks in any changes to svn (or RCS. easily modified to use other revision control systems). On machines which are part of a load-balanced setup, it even ssh-es into other machines in the array, runs “svn update” and “make” to ensure that the vhost is operational on the other machines too. Finally, it concatenates all the active config fragments into one large file because apache reloads a LOT faster if it doesn’t have to load hundreds of little config files. 2. Removing a vhost is as simple as editing virtual-hosts.conf and commenting out or deleting the line, then running make again. virtual-hosts.conf The virtual-hosts.conf file is extremely useful. It gives me a single authoritative source of all the relevant details about EVERY vhost running on a machine. These details can be used by other scripts (e.g. cron jobs to run webalizer, analog, htdig indexing, webcheck, etc; cgi scripts to display a list of vhosts on the machine with clickable links, and more). This single config file makes the whole system easily extensible: write a new script to parse the config file, and loop through each entry, performing some relevant operation. e.g. run webalizer for every vhost, dumping the output under ~/public_html/LOGS/ (with optional .htaccess file to control access). Adding optional generation of samba shares for each vhost was quite easy. In theory, it wouldn’t be hard to put a GUI or web front-end on to it. Oddly enough, i’ve never bothered. And I’m not inclined to bother now (but wouldn’t object if anyone else did) Database? no, thanks I’ve occasionally thought about putting this config data into a database, but the benefits just aren’t anywhere near good enough to outweigh vi and all the benefits of text file configuration (especially comments!) Packaging? And, of course, one of these days, i should package it all up for debian. I’ve been saying that for years, and just haven’t got around to it. It wouldn’t take a huge amount of work to do so, there are only a few small things i need to do to automate the installation, things that i just do by hand in a few minutes when installing on a new box. Before packaging it, I also want to automate the adduser part of the process, as well as creation of postgres or mysql accounts. Most importantly, I ought to separate the code from the templates in the config fragment generator scripts, so that the local sysadmin can edit them without having to edit the scripts….OK, all up not a tiny job but not particularly big either….just big enough to be ignored on my TODO list for years. I’d definitely have to change the config file format from the current one-line (colon separated fields) to using a .ini style file. I’ve wanted to do that for a while but have inertially-resisted it so far because the one-line format is so convenient…unfortunately, I’ve added so many flags and features over the years that it’s seriously ugly - probably scary to someone who doesn’t know it already (i.e. anyone outside of the set of “me + a handful of other people”). I estimate this would take about a days worth of hacking I’d also take the opportunity to clean up some of the cruft :-) Essential Design Criteria BTW, one crucial design criteria for my system is that it should *NEVER* under any circumstances overwrite any hand-edited changes. This is implemented in a number of ways. First, it takes an md5sum of each vhost’s config fragment when it generates it. If/when the script is run again, it only re-generates the config fragment if the md5sum hasn’t changed. If it has changed, it generates the updated fragment as “.new” for manual merging if required. Secondly, when generating conf fragments it looks for specially named files in a directory for extra stuff to add before the <VirtualHost> line, between the <VirtualHost>…</VirtualHost> lines, and/or after the </VirtualHost> line. This is to provide another location to put custom changes for each vhost while still retaining the ability to have improvements/new features to the script automatically applied to existing vhosts. The reason for this is that I utterly loathe and despise allegedly “easy” configuration tools that blow away custom hand-edited changes. I hate them so much that this was THE major incentive for developing my own vhosting system. In Use I’ve been using my system for over 10 years now. It grew out of earlier bits and pieces, but the current incarnation has been working since 1999, with the occasional new feature or update (e.g. to add support for apache2 as well as apache1, and minor changes to adapt to changes in debian’s apache packaging). There are also a handful of ISPs and several small businesses around Australia running it because they’ve hired me to set up their web servers. Finally… My vhosting system isn’t a system for people who are scared of or dislike command-lines or text-file configs. It’s a system for people who love them, but want an easy way to automate a dull, repetitive task. Such automation is easy for CLI tools, and next to impossible for web/GUI tools. Syndicated from Craig Sanders' Errata: Miscellaneous Thoughts poll: package my vhosting system for debian?

The Bandwidth of Code:

Hell is Other People's Code is, perhaps, another way of saying that code is a terrible way to communicate with other human beings. Foreign code inspires a mixture of apprehension, anger and anxiety precisely because the bandwidth capacity of written code is so horrifying small. Enormous amounts of context, nuance, philosophy, history -- in short, knowledge -- is lost forever each time we try to translate our ideas and desires into program code. And this tremendous loss of knowledge looks to be unavoidable.

Since even Knuth has given up on literate programming as a general solution to this kind of problem, let me throw another possibility out there: Version control. It's not perfect, but you can get into someone's head by reading their mistakes and false tries in their version control history. This is why rebasing is bad. But also why it appeals to so many developers, who have no desire to let you inside their head. Steve Yegge Steve is very quotable. From Xemacs is dead, Long live Xemacs:

XEmacs should drop out of the race At this point it's becoming painful to watch. GNU Emacs is getting all the superdelegates. That warmonger VIM is sitting back and laughing at us. But XEmacs just won't quit!

And has some deep insights into the mind of an emacs user. From the Pinocchio Problem:

Viewed from a radical, yet possibly defensible perspective, a reboot is a murder.

And some things that ring true (or at least provide another excuse for not learning haskell properly). Also from the Pinocchio Problem:

There's nothing wrong with static type systems. You just have to realize that when you use them, you're building hardware, not software.

Best of all they're in these enormous long blog-rants of chapter length that discuss a topic in depth, then go out the other side. Great fun, even if you disagree with him. sad end SFGate reports:

Reiser is guilty of first-degree murder, the jury has found. He killed Nina with premeditation and deliberation and now faces 25 years to life in prison. Pressed to elaborate, Du Bois said, "I'm sure he negatively impressed the jurors."

Hans also mostly negatively impressed me the one time I met him (and the one time I emailed him). And the whole business of hiring Russian programmers to slave away at a filesystem with your name on it has always struck me as shady and disenfranchising. But, after reading Rick's excellent summaries of every day of the trial, I still have no idea if Reiser killed his wife, and indeed no clue if she's dead at all, or instead back in Russia with the children.

I've got most of the build system / packaging stuff done for estron now. There's a basic Yelp manual pending completion of the Estron GNOME application, there are some refreshed screenshots, updated the website CSS and added an icon, updated Glade files using Gtk stock items for the buttons.

http://estron.alioth.debian.org/

It's grown into yet more packages from the one source:

ii  estron                0.7.0-1  data-centric development interpreter for GNOME

ii  estron-doc            0.7.0-1  data-centric development interpreter (help files)

ii  estron-gnome          0.7.0-1  data-centric development environment for GNOME

ii  libestron-dbg         0.7.0-1  estron debugging library

ii  libestron-dbi-driver  0.7.0-1  DBI driver for estron

ii  libestron-dev         0.7.0-1  estron development interface

ii  libestron-doc         0.7.0-1  libestron development documentation

ii  libestron-odbc-driver 0.7.0-1  ODBC driver for estron

ii  libestron-pg-driver   0.7.0-1  PostgreSQL driver for estron

ii  libestron0            0.7.0-1  data-centric interface support library

Only the docs are of any particular size - the interpreter is tiny. (estron-gnome is simply an estron file and companion glade file, run by the estron interpreter so it's Architecture: all like all estron applications.)

Lots to do still - upgrading the Gtk code, adding new features to the interpreter to fully support the development environment and finally putting some details into the user manual (estron-doc) - but at least the package builds easily and cleanly. Once I have a working estron-gnome setup, I'll put the POT file out for translation too (around 120 messages so far).

There isn't any need for debconf and things, this will use existing database configuration tools like mergeant - that needs work too because current estron example files have hardcoded database connection strings.

I like them. And if there is such a thing, I hope they carry good luck with them - Not that I believe in good luck, but anyway - Yesterday was a very good day, in quite many fronts. And it's nice to make a nice, closed leap on so many bases:

>> puts [was,am].map  age  [98,111,100,120].map  s  sprintf "%# s.chr ", age .join(', ') 
11111, 37, 31, 1f
100000, 40, 32, 20

And just for coolness sake: It gets even better when looking at coincidence with my father - at least for the next couple of months:

>>puts [f_was, f_is].map  age  [98,111,100,120].map  s  sprintf "%# s.chr ", age .join(', ') 
111111, 77, 63, 3f
1000000, 100, 64, 40

So, in most useful systems, we are both in a very nice and closed number. Sadly, I can no longer say that five bits should be enough for anybody.

As I wrote some time ago, I did consider switching to a new blog software, the OpenSource Edition of MovableType. I’ve actually done that some 6 weeks ago and must say - it is one browser based application I am actually happy with for myself. (Good god, I must be really ill). I know that about all the things that changed in my blog, compared to my old blosxom based version, are actually doable with blosxom too. For some reasons I just never got around to doing it. Anyways, some things I still remember that changed:

• I got comments and trackbacks support. Not that anyone except spammers and myself did use trackbacks yet, but comments got used, especially in the last few ftpmaster and delegation related posts. Also, the Anti-Spam plugins you get with MT version 4.1 are pretty good. I haven’t had a spam trackback show up yet. They all directly go into the Spam area, which I sometimes just delete. Same for the comments. As I’ve set it up that all comments need approval (unless someone already made a non-spam comment so I set them “Trusted Commenter”) and also have to pass the spamfilter I haven’t had a problem with spam comments. And while I offer 7 different ways of authenticating yourself when you want to post a comment here, including the famous anonymous way with a captcha - only one spam comment got in yet.
• Comments and Trackbacks are automagically closed by a Plugin when the entry reaches an age of 30 days.
• I now can do “Scheduled” posts. Within blosxom I would need a cronjob that copies the file with the blog entry into the right dir, in MT I just select the posting time in the creation window for an entry.
• The category system, especially with having one entry appear in multiple categories, seems to be way simpler. Including the ability to easily generate per-category rss feeds.
• MT generates (in default setup) static pages. Only the comment part is not static (hehe, of course not).
• Editing no longer resets the published time, which blosxom based on file timestamps. I can edit as much as I want, the entries keep their time. Unless I manually change that time.
• MT also seems to be able to handle your whole homepage. And file storage. And cms like (with plugins, afaik). And whatnot. And is “multi-author” capable. And multi-blog.

What it not has is the ability to use a version control system for your posts. Of course not, its a web based editor which stores its data in a database. Oh well, lets stop here, basically - I just like it. :) Comments: 0

Guess I got your attention with that title? :) Anyways, britney is no longer. And with her testing died too. Ok, not really, but todays work was hand over all of testing and put it where it should have been for years - in the hands of the release team. For those not following the “inner” workings of stuff:

• Testing is the place where our next stable release gets prepared. It is managed by a software called britney, which was written by Anthony Towns.
• Britney was, until today, run by the ftpmasters. The release team had no way to change anything, besides their hint files. They couldn’t change code, couldn’t rerun it themselve if needed, nothing. (Somewhere in the past, for some period, some of the release team was able to do extra britney runs, AFAIK, but thats long ago).

As the above is surely not nice, especially as Anthony (and as such the one in ftpmaster who really fully knew britney) left the ftpmaster group, all of the code managing testing now lives with the release team. They now just prepare a file in a special format and then tell us (via a ssh trigger) to read that in. Which simply sets testing to the new state. This new way of doing things has multiple advantages:

• The release team can run britney whenever they want to. It no longer needs to wait for a cronjob at some externally defined time or ping an ftpmaster to do an extra run. That should be pretty helpful, especially when we are near to a release again.
• They can do code changes or even replace the current britney with a totally new one. (There seems to be a new one available that does the same as the current one, just way faster. Or even more. Which never seems to have got any comment from our side. Badbad. Well, now they can play with it if they want to.). As long as they output valid data for us to import, it is now completly their decision how it gets generated.

The above action did need surprisingly few code changes in dak. It basically was

• disable the cronjob for britney as user dak
• Add a script that the release team now pushes via ssh. This script reads in the above mentioned special file and sets the database.
• Change process-accepted to write the urgencies to a different directory. And no longer try to mkdir this directory, but warn if it doesn’t exist (or is not writeable by dak) and then use a temporary one for the run.
• Move the transitions.yaml to a different location and add a redirect in apache, so everyone can still access it from outside. (It has to live in a ftpmaster controlled directory, thats all).
• Eliminate a britney call from our daily cronjob.

Comments: 8

Since I didn't find a similar tool for Linux, I've hacked together a tiny tool to do BPM counting. The usual stuff: tap any key with the music to get a BPM estimation. There is no music analysis done.To achieve better results, my tool uses an exponentially weighted average. It also computes a confidence interval. So if the song changes tempo (and quite some jazz songs do) or doesn't keep the tempo constantly (live music with human drummers often shows some tempo drift. It's just the drum computers that keep their speed very well...) - the tool can handle that quite well, while also not being overly sensitive to tapping errors (as you can see in the image).I figure there might be even better estimation tricks (e.g. doing some error detection and removing them), but this one was just very simple to implement. And by looking at the graph and the error interval it's quite easy to check that you didn't any recent mistakes and the result is okay.The Python code is about 158 lines SLOC, and a small UI description generated with Glade. It's built with PyGTK and uses Cairo for the plots, so it should be very platform independant and even run on Windows.Download will be available sometime when I get around to clean it up a little. There is for example still the code in there to compute plain averages, which can't handle songs with multiple tempos at all.[Update: it now also has a tiny 'flasher' icon that will show you the current tempo estimation. This is great for checking the quality of the result - if it keeps on flashing in sync with the music after you've stopped tapping, it's good. I was also pointed to GNU GTick which is a full featured metronome application and also has a tap button.]

Hey'all! Another update of the moment:

Physio is going amazingly well. I feel like my neck / shoulder mobility is close to what it was pre-surgery. My strength is still lagging behind, and I'm doing hefty 3 pound bicep curls! Woohoo! Not so much for my arms, but for my back, which still has to support my arms doing this. I'm also doing 45 pound dips, and some exercises with a yellow theraband. Walking is really tiring me out at all anymore, no matter what distance I walk. As I'm reducing my pain meds, I am starting to get sore, though. Hopefully in the next week that will stabilise. Next Monday I get an ultrasound of some internal organs (I can't remember which, sorry) that will see if I have a non-drug related cause for the ongoing nausea. But so far a pill every day or two seems to be keeping it at bay.

I've posted two more videos of Leif up on YouTube. I have a bunch to sift through, but hopefully there's at least one more good one in the set. I haven't uploaded the pictures yet because I hate f-spot so much. (Ask my sometime why I think it was called f-spot)

I got a fun chain letter from someone asking everyone to boycott Esso and Shell for the rest of the year to force gas prices to come back down the sub dollar-per-litre. This was my reply:

I like high gas prices, though. I want the prices to go much higher.

Every time the prices go up, there are more cyclists on the road, and
the air gets a bit clearer.

If it were $10/litre, then almost noone would drive. We'd all be on
bicycles. Then it we be so much safer to be on a bike.

I can't wait for the day.

What do y'all think?

And on the hacking front, I actually dusted off CVS and fixed some autotools bits in GNU Sysutils so that David could fix a compile bug. I don't know if this round of activity will spur us into doing more. But it's possible. So maybe in another.. Oh, I dunno. decade or so we'll have a full GNU replacement for util-linux that's portable and everything. =)

I might get off my ass and hack on my reimplementation of Galactic Bloodshed through the month of May. I miss that game in a strange pathetic way.

Heading into my last month of off-work recovery time, I'm surprised at how good I feel. I haven't replied to alot of emails I've gotten from folks, even from before the surgery. I'm starting to make headway on the emails, though. Thanks for your patience!

Hugs all!

Andrew Binstock interviewed Donald Knuth recently, and one of the more amusing tidbits was this:

I currently use Ubuntu Linux, on a standalone laptop it has no Internet connection. I occasionally carry flash memory drives between this machine and the Macs that I use for network surfing and graphics; but I trust my family jewels only to Linux.

More seriously, I found his comments about about multi-core computers to be very interesting:

I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they re trying to pass the blame for the future demise of Moore s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the “Itanium” approach that was supposed to be so terrific until it turned out that the wished-for compilers were basically impossible to write. Let me put it this way: During the past 50 years, I ve written well over a thousand programs, many of which have substantial size. I can t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX…. I know that important applications for parallelism exist rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years.

This is a very interesting issue, because it raises the question of what next-generation CPU’s need to do in order to be successful. Given that it is no longer possible to just double the clock frequency every 18 months, should CPU architects just start doubling the number of cores every 18 months instead? Or should they try to concentrate a lot more computing power into an individual core, and optimize for a fast and dense interconnect between the CPU’s? The latter is much more difficult, and the advantage of doing the first is that it’s really easy for marketing types to use some cheesy benchmark such as SPECint to help sell the chip, but then people find out that it’s not very useful in real life. Why? Because programmers have proven that they have a huge amount of trouble writing programs that take advantage of these very large multicore computers. Ultimately, I suspect that we will need a radically different way of programming in order to take advantage of these systems, and perhaps a totally new programming language before we will be able to use them. Professor Knuth is highly dubious that the later approach will work, and while I hope he’s wrong (since I suspect the hardware designers are starting to run out of ideas, so it’s time software engineers started doing some innovating), he’s a pretty smart guy, and he may well be right. Of course, another question is whether what would we do with all of that computing power? Whatever happened to the predictions that computers would be able to support voice or visual recognition? And of course, what about the power and cooling issues for these super-high-powered chips? All I can say is, the next couple of years is going to be interesting, as we try to sort out all of these issues.

Lessons learned today:

• Assembling a bunch of kitchen cabinets is no easy feat. While assembling a bit of IKEA furniture is usually done in 30-60 minutes, assembling 4 cabinets took all afternoon. And we're only halfway through.
• Apparently, Gamma will not double-check that the package you receive from them is complete—the drawer set for the 30cm cabinet wasn't.
• Sometimes, being helpful turns out not to be. The Gamma kitchen cabinets come with some of the metal bits already in the wood. Due to this, I had not been able to form a mental picture of what the metal bits look like; and as a result of that, we damaged some of the cabinets (though luckily not critically).

Anyway, the bottom half of the kitchen is now assembled. Sortof. The upper half, we'll probably do tomorrow. Or, er, well, "today", since 5 minutes ago... Other than that, there's still much work to be done: Do something about the holes in one of the walls, treat another one of the walls for water damage, finish the paint job. Next tuesday and wednesday, a plumber will be connecting the kitchen sink and most of the plumbery in the bath room—hence the need for the assembly of the kitchen before that time. After that, I'll probably need to finish off some other things as well... Oh, well, and I'll also need to move, of course. In case you've been wondering, yes, this is why I haven't been very active on the Debian front lately. I've been signing my buildd mails (although not usually as prompt as one would expect), but that's about it. As a result, I got NMU'ed for the first time in my career as a Debian Developer—by two people at the same time, no less. Feels rather strange, I must say.

Apparently the use of the terms describing free software as organic or non-organic depending on the extent to which the piece of software concerned is controlled or driven by a single company wound a few people up, partly due to the strong value judgements that the terms tend to imply. The terms I found myself using in a conversation about web frameworks with some Scotland on Rails attendees were commercial and corporate. These apply better in the web sphere where the business side of things is much more to the fore than it is in most free software work but the principle is there. Money floating around isn’t an issue, it’s the extent to which you have to deal with a particular company to get things done that makes the difference.

Last night, my flatmate asked the question of whether it is possible to do anything in a selfless way, or whether everything one does can be traced back to one s own interests. I am not fit for these kinds of philosophical arguments anymore, so we pursued another topic instead. Today I am sitting on a Swiss flight and am being bombarded by commercials on the stationary television screens they use for safety instructions and the onboard entertainment. Swisscom purchased advertising space, and there they proudly let us know, in German, English, and French that 1 million kids in Switzerland jump for joy as Swisscom brings free Internet access to their schools. Simply so. (sic). When I read this, I first though: why the heck are Swiss schools still in need of Internet connections? Why do we tolerate an economy or situation in which the Internet isn t ubiquitous yet? And then, my mind suddenly made the connection to last night s discussion on selflessness: even though Swisscom is trying to communicate that they re being selflessly good by providing access to the school s, they obviously aren t, or they wouldn t be using the factoid for advertising. The curious aspect is that I wouldn t normally have absorbed their message or linked it to last night s discussion. The reason that I did is because of the gross errors in their English translation. The German einfach so , which I think they translated wrongly, suggests that they did something without any particular reason. I am not a native English speaker, but simply so doesn t exist, and it (thus) doesn t have that meaning. Dear Swisscom, and all other companies who think that English is hip, or who actually want to reach out beyond the borders of four-language-Switzerland: consider employing someone who can speak the language to help with your marketing. Even if you want to let the world think that what you do is without commerical interests. NP: The Flower Kings: Unfold the Future Update: initially, I criticised Swisscom for using jumping for joy , which makes no sense to me. Apparently, however, it s an idiom. I should have checked, especially since I am criticising the use of a language non-native to me. Thanks to the various people who wrote in for kindly pointing out my mistake.

In this post, Steven Hanley wonders how to keep /var/cache/apt/archives empty on a machine that has a full mirror of debian on it. That’s actually the wrong question. The right question is ‘Why is /var/cache/apt/archives even relevant on a machine with a full mirror of debian?’ /etc/apt/sources.list has always supported file:/ URLs. for example, sources.list on my local debian mirror looks like this:

deb file:/home/ftp/debian unstable main contrib non-free
deb file:/home/ftp/debian-multimedia/ unstable main

With a file URL, apt-get doesn’t need to download any packages, and thus doesn’t need to cache anything in /var/cache/apt/archives. No need to keep it empty, it just is empty. In a related post, Andrew Pollock suggests adding DPkg::Post-Invoke “apt-get clean”; ; to /etc/apt/apt.conf. That would be fine if you ONLY ever ran “apt-get update ; apt-get dist-upgrade”. It’s not fine if you run “apt-get -d” to download packages first, then install a few packages with “apt-get install package”, and then run “apt-get dist-upgrade”. If you try that, then the DPKG::Post-Invoke rule will clean out /var/cache/apt/archives when you install the individual package(s). When you then run the dist-upgrade, apt-get will have to download all the packages again. Better just to get into the habit of running apt-get clean or autoclean occasionally when you want to reclaim some disk space. Syndicated from Craig Sanders' Errata: Miscellaneous Thoughts Keeping apt archives empty…or not.

Following my first ftpmaster blog post, which got some nice replies, lets have the next, as I didn’t stop working on stuff. Not as much as I hoped, but well, something. So, what was done since then?

• Merged a little patch from Christoph Berg fixing usage of a function - which doesn’t exist in global namespace, so it needs the full name.
• Merged another patch from Christoph - now we write the content of the Changed-By field from .changes files into projectb. To cite him for the reason: This will allow to identify NMUs and sponsored uploads more precisely in tools querying projectb. Broke dinstall with this and as a little side-effect also the merkel copy of the projectb database. Ups. Well, fixed it immediately again. :) There is some old data available, which I could import into projectb, so it would have data for all packages. But there is some weirdness with the dataset I got from Christoph and am waiting for him to provide a solution. Anyway, all new uploads already store this data, so it is only old data missing, currently.
• Merged a small patch from Thomas Viehmann into our archive software which enables it to send a copy of all mails to the person sponsoring the upload. This is in affect for all future uploads, not for any package which already hit the queues (like those in NEW right now). We do
  • only sent the extra copy if it is a sourceful upload, to not spam buildd admins,
  • only sent the mails to sponsors who did not disable their @debian.org address.
  For those interested, the process works similar to:
  • We look if the Debian login attached to the key signing the upload has an active @debian.org address.
  • If that is the case we look for all uids on that key that look like an email address and compare them with the Maintainer: and Changed-By: field in the .changes file.
  • If there is no match, ie. none of the “emails” of the key uids is in those fields, the @debian.org mail is added to the set of valid receivers.
• Changed split-done to only move files older than 30 days and let it run by our weekly cronjob. Also run it once, which moved 120079 files into their $YEAR/$MONTH subdirectories. (split-done seperates the subdir where we store every .changes of uploads accepted. That quickly grows fast, and we all know how bad filesystems perform with such a number of files. The above 120079 files are from November/Dezember 2007 til now, so imagine how many we have in total, as we have them back to 2002).
• Merged a patch I wrote 7 days ago that does a little sanity checking in the Provides field. Do not try to version your provide, that is forbidden and actually breaks software. (See this bug about it.)
• Merged a patch, submitted by Marc Brockschmidt some long time ago, that lets cruft-report also display NBS for experimental. Changed the cron script to use that extra feature.

---

And as in my last blog post, lets add some items to the todo list:

• Enable dak to read a Built-By field from the .changes file. Thats the sanest solution to sponsored uploads. And also better for buildds, they then should no longer overwrite the Maintainer field with the -m parameter when building packages. Exact semantics to be defined, but dak probably would go something similar to
  • Built-By same as Changed-By or Maintainer?” - do not send mail there.
  • Built-By differs from Changed-By or Maintainer and its sourceful? Send mail to it too.
  • Built-By differs from Changed-By or Maintainer and binary-only? Only send mail there.
• Track the Uploaders: field in projectb. That would help the BTS to offer another display.

Having written all this - today (AKA Saturday, when writing this) won’t see code merges by me. I think most of my ftpmaster related work today will be fun with the NEW queue. For some unknown reason people keep uploading packages. Tsss. Comments: 3

It seems existing versions of gcc don't warn when you use an assignment as a truth value as the first operand to the conditional operator. For example: Presumably you meant ==, but unfortunately that does not warn with gcc (maybe it will one day). We can use the tree dumping mechanisms (previously mentioned here) to confirm our problem. For the following function gcc creates: As you can see, this isn't the result we wanted. This can be quite nasty if you use the conditional operator in a hidden fashion; for example behind an assert. A common idiom is: You'll currently get no warning you've slipped up and used the assert wrong. Moral of the story: a quick audit of your code might turn up some surprising uses! However, in this case, the Intel compiler picks this one up: Although it's often not trivial to move to another compiler, as a rule I would recommend trying alternative compilers for your code as it's a great sanity check.

One week ago, I went to a branch office of Servicio de Administraci n Tributaria, the government office in charge of processing taxes. This year, I plan on doing something quite bold, as my Mexican friends will acknowledge: I will prepare my (quite simple, I hope) tax declaration by myself. I do not want to be held hostage of the accountant guild - So I might end doing some fuckup which in the end costs me money or time. I hope it is not the case.
Anyway... Last week I went to this office, as I needed either a CIECF (Clave de Identificaci n Electr nica Confidencial Fortalecida - Strengthened Confidential Electronic Identification Key) or a FIEL (Firma Electr nica Avanzada - Advanced Electronic Signature). No, please don't believe it is a security token, a card with printed numbers, a one-time-pad or the sort - The CIECF is... A password. Why is it strengthened? Because it has the feature of including a question, in case you forget the key, to allow you to change it. I guess the FIEL is a more reliable device, but I prefer not to even request it.
And as far as the questions go, the emergency questions for CIECF suck. First, I was not even asked the meta-question - I was not told why this information was needed. So imagine the clerk saying: Full name? ... Date of birth? ... RFC (Tax ID)? ... Favorite color? I was there just... Stunned. Why do you need it? Oh, just in case you forget your password. Ok... Don't you have any other questions which I am not prone to answer a different thing, and that are not dead obvious for a casual passer-by? (I guess that at least 1/4 of the public will say blue. Feel like brute-forcing SAT to its knees?) Other questions include your fathers' second family name, your favorite soccer team, your pet's name... It seems they took the first "security dos and don'ts" book off the wall, and started reading backwards.
But anyway, that's the system, and I must play nice with it. So I get back home, and decide to start hacking up my declaration. No, Mr. Policeman, I'm not saying I would try to break into the SAT - I just say it is a complex and non-obvious task to do. Now please release me. Thanks.
And I enter the system. Of course, I tried first with Iceweasel, knowing it would fail (it is documented: MSIE 5.5 recommended). I tried again with Konqueror. I tried, sigh, with MSIE from inside Wine. No luck. Well, even from within qemu's Windows 2000. Wrong password. WTF?! Stranger: It worked with SAT's My portal, although it didn't with the declaration, which is what matters now.
I cannot take the time every day to come to the SAT and move my data - It was a full week until I came back again. I insisted on fully logging in to the system, to be sure the password I entered this time was right. As well as my ber-secret safety question, of course.
And it failed.
Twice.
Until the clerk noticed something strange in the way I typed...
Sir, excuse me..., he muttered, why are you typing such a long password? Well, basically because I value my tax declaration, and I know brute force is a powerful force. (explain it, of course, in simple terms) Oh... No, the password must be eight characters long.
No wonder.
So I entered the first eight characters of my password, which was a true work of prose for their standards, at around 20 characters. And it worked.
Now, for bonus points: What do we gather from the fact that the long password works fine in one system, but in another system it only the short version? Why, but of course! I guess the passwords for every economically active Mexican is stored in their master database in plain text. Isn't it just beautiful?
Anyway, it seems I have a lot of work to do. If all goes as planned, maybe next year I will be for hire as a public accountant? Hmh, does not sound too much like fun, does it?

I recently read about the Open Source Census and thought it would be a nice thing to also put my vote in and make sure my operating system of choice was properly represented (currently it doesn't seem to be). After creating an account there, downloading a 45M tgz including among other things a complete java runtime environment, starting the scan tool that takes neither a -h nor a --help parameter and watching it hog 70% CPU for over 20 minutes I lost patience and killed the script. Somehow this whole thing is not exactly inspiring confidence and I start getting an idea why there are currently (Thu Apr 24 12:47:57 CEST 2008) only 53 Debian users who submitted their data. Although it's a pity Debian is (and will probably continue to be) so underrepresented there, I can't say I blame anyone for not taking part.

In the last leg of what has been marathon traveling over the last two months, I'm going to be heading back to San Francisco to give two talks at CommunityOne. CommunityOne is a new one-day conference that Sun is putting on -- along side it's massive JavaOne conference -- that focuses on free software, open source, and non-Sun projects. I'm going to be there talking about free software and free culture. I will be giving updated versions of the two talks that I have at the FSF members meetings over first two years. In the first talk, I'll be making the case for a strong free culture movement and in the second I'll be talking about liberating network services. If you will be at the conference, or just in the Bay area, and would like to meet up, I'll be in the area for most of a week and would love to arrange something. Just get in contact.