The recent announcements by McCain and Clinton of their support for a temporary repeal of the Federal gas tax make me sick. More on why later, but first, I want to put forth my idea. I think both Republicans and Democrats would like it -- as it's based on market principles and achieves a reduction in costs to the average household, while simultaneously helping the environment and reducing our dependency on foreign oil. But of course, it's courageous, and we don't have many politicians of that type anymore.

What we need is a large, revenue-neutral, gas tax increase. Now, before people go nuts, let's explore what this means.

Revenue-neutral means that it doesn't result in a net increase of monies going to the government. The increase in the gas tax rate is offset by a decrease in the income tax, tied to the cost of direct and indirect taxable gasoline each family or business consumes. So on day 1, if you cost of filling up at the tank goes up by $10 in a week, if you are an average family, your total paychecks also go up by $10. Your cost for receiving a package might go up by $1, and your paycheck goes up by the same amount. So you're no worse off than before -- if you're average.

Let's look at the pros and cons of this sort of plan:

• The economic incentive to be efficient consumers of gas is magnified. This will eventually lead to Americans having more money in their pockets, increasing market incentives for fuel efficiency, and a decreasing (or increasing slower) price of oil as demand slows.


• Economic incentives to use mass transit, live close to urban centers, or drive fuel-efficient vehicles are magnified. Likewise, the economic incentives to invest in mass transit and efficient automobiles are also magnified.


• As more efficient technologies come on the market, and Americans decide that they'd like to pad their bank accounts by hundreds or thousands of dollars a year, more sustainable and environmentally-friendly development patterns will emerge. Also, the price of oil will be kept low. Of course, people that choose not to change will, on average, be no worse off than before.


• Alternative choices to the automobile will have a greater incentive to develop. Think the return of a fast, speedy national passenger and freight network, greater mass transit options, etc.


• The marketplace will drive Detroit to love making fuel-efficient vehicles, because they will be the new profit centers.


• This sort of thing is known to work well in other countries around the world.

If we think more long-term, we see even more positive effects:

• The return to local agriculture and manufacturing. Due to lower transportation costs, local farmers and manufacturers will be able to undercut Walmart's prices due to the larger relative costs of Walmart's much-vaunted national distribution network. Unless, that is, Walmart starts buying local -- which is a good thing too. This is a good thing for American jobs.


• Keeping all that oil money in the domestic economy is a good thing for American jobs, too.


• Our businesses will have a jump start on being competitive in the increasingly carbon-regulated global marketplace.

As for the cons:

• Eventually this will lead to a net reduction in Federal revenues as efficiencies develop in the marketplace and people save money on gas. Corresponding budget cuts will be required. (A good thing, I figure)


• Implementing this all at once would be a shock to some people living inefficiently now -- those that are far above average. It would have to be implemented gradually to avoid being a shock to the economy.

Now, for the McCain/Clinton plan: it's a farce. Reducing the gas taxes means more efficient gas, which means more consumption of gas, which in turn leads to -- yes -- higher gas prices. Its real effect will be minimal, and is a terrible long-term policy. It charges tens of billions of dollars to the national credit card (which we, and our children, will have to repay) while achieving almost no benefit now. It's a gimmick through and through, and something that says loud and clear that neither candidate is on track for the "Straight Talk Express".

Update 4/29/2008: One potential solution for the problem of declining revenues over time is to periodically re-index the averages to mirror current usage. Assuming this does really lead to the expected drop in consumption, there is no sense in 2020 of paying people for how much gas they would have used in 2008.

When I heard that there will be a miniseries based on “The Andromeda Strain” book, I was very exited. That was one of my favorite sci-fi books in my childhood. After watching the miniseries I must conclude that this is another book perverted and trivialized by Hollywood. SPOILERS AHEAD! They created some crazy pseido-sci-fi idea that humans from the future sent Andromeda back from the future via a wormhole in a container that contained a message which was then picked up by a satellite that was sent up to investigate the wormhole. No wormhole was there in the book. The book had a much more modest idea - a Scoop satellite was to skim the outer layers of the atmosphere for mutations of common Earth bacteria for military purposes when it was impacted my a micrometeorite carrying the Andromeda. Much more probable, no need to involve wormholes, time travel, ASCII messages, eco-terrorists and a sub-plot on conservation of marine species. Due to extreme modernization of the script, the whole subplot of the teletype mechanical failure was omitted. Andromeda was made sentient instead and communicated via ’some kind of inductive field’ to shoot down a fighter jet and activate a nuke. The survivors and their pH levels got barely a glance. Also the amount of destruction was obviously too low for the movie, so the Andromeda was made to mutate more, spread out of containment easily and even make a flock of birds attack a squad of solders ‘Hitchcock style’. Disgustingly cheap scriptwriting. Huge chunks of plot were ripped out (searching for the micro-meteorite impact crater with different lenses, central core security) and the two hours were filled with Rembo style journalism vs. black ops, selfless president and scenes of animals eating each other and dieing. At the end they ran out of budget and just made it look like presence of Andromeda made air and water bright red so that people would have something to run away from in fear. Oh and the scientists are allowed to freely talk about the event after it’s done. Yeah, right. In my book this movie rates very close to the infamous “The Core” with the only difference that they managed to fuck up a really good book. Do not watch it and read the book instead.

Ira Pramanick talks in her weblog about a mentorship program targeted towards middle and high school girls to foster in them a positive attitude towards computing. The program is called MAGIC, which stands for More Active Girls In Computing, and tries to address the issue of the low number of girls entering the computing and high tech world. As they say, it is a serious issue caused not by then lack of talent, but due to a bunch of discouraging factors that exist in our culture and society. Right now, women represent only about 28% of the technology workforce. I don’t know if a mentorship program dedicated to these girls would be enough to increase the number of women participating in the technology workforce, but it will probably help to improve the situation. It would be nice to import the project model into Spanish speaking countries if it’s successful. The Mentor Qualification Process is quite strange anyway. It might be that we europeans have cultural differences, but I find some of the questions there quite disturbing, like “Are you willing to be finger-printed and screened?”. I don’t exactly know what they might want such a sensitive data for.

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?

About gobolinux

I can suspend my laptop and it restarts happily enough in X, but playing video results in a strange green square. I've found that starting and killing another X server (like X :1, wait for the grey mesh and then zap it) fixes the problem and I can switch back to my original :0 X and play video again. I wonder if these notes on X suspend and video BIOS by Matthew Garrett explain it.

About debian

Why on earth did someone change the .changes format so swiftly and why does a change that breaks a common upload process (build in a VM, sign on a stable system) only warrant a -devel-announce paragraph under the headline Misc Development News (#6)? "Small news" - my foot!

I haven’t had my virtual victory lap yet, so here it is:

I've been using GMail ever since they decided to allow users to download their mail using POP. I was happy reading my email as usual in mutt. The only problem was that I had to log onto the website once in a while to clear out my spam folder and fish out the false positives.

However, as the amount of spam I receive daily started growing exponentially (in part thanks to my involvement in Debian), I became more and more dissatisfied with this solution. I had to login several times a day just to keep the levels of spam down to a manageable level. I tried emailing the GMail support team a few times without success.

The solution came just as I was looking at switching to a different email provider: IMAP access.

Using fetchmail, I can now download my received and sent mail using POP and then download (and purge) the contents of my spam folder. Here are the relevant lines of my ~/.fetchmailrc:

poll pop.gmail.com protocol pop3 user "fmarier@gmail.com" is "francois" password "" fetchall ssl
poll imap.gmail.com protocol imap user "fmarier@gmail.com" is "francois" password "" folder "[Gmail]/Spam" fetchall ssl

I can then run all of my mail through my own SpamAssassin filter (to which I added these excellent custom rules) and sort my mail in one of three folders:

• definitely spam (conveniently located in /dev/null) for a score greater than 12
• probably spam (I need to check those manually once in a while)
• not spam for messages with a score less than 5

This is done using procmail with the following bit in my ~/.procmailrc:

# Use spamassassin to check for spam
# (only check messages 400kB so that it doesn't choke) :0fw:/etc/mail/spamc.lock
* 409600
/usr/bin/spamc

# Throw away messages with a score of > 12.0
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

:0:
* ^X-Spam-Status: Yes
/home/francois/mail/spam

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.

When I got in to my hotel room last night, it was brightly illuminated and the TV was on with music and a message to greet me. The first thing I did was turn it off, along with most of the lights. Later, I asked at the reception when they turn on the lights. I was expecting them to have a central switch for each room that the receptionist could flip when the guest finished checking in and has started to make way towards the room. Not so. The guy behind the desk told me that housekeeping sets it all up. So my lights have been on and the TV blasting for the entire afternoon and evening. That did not make me feel at home. It made me cross. NP: The Pineapple Thief: 8 Days Later

Debian wants to release in september. This target is already becoming difficult to reach, though the Release Team would like to try to do an extra effort to reach it. History has shown that as long as testing migration is not frozen, many maintainers don't care much. Even during the freeze 'small' bug fixes are uploaded that sometimes break a lot and can delay the release quite a bit. Currently build-essential packages are frozen, though 13 of these have new uploads in unstable... We do want to finish 2 major transitions: python 2.4 -> 2.5 and perl 5.8 -> 5.10 before also freezing the non essential toolchain. The first one is reaching an end, though some build failures on arm and a flaky alpha buildd are not helpful in that regard. Note that during a freeze fixes for release critical bugs, release goal bugs, documentation issues as well as translation bugs should still be fine if they have a low impact. Please do send unblock requests for those to the Release Team. Considering all the above I do hope that maintainers start to realise that requesting freeze exceptions (exceptions to the above guidelines) should not be done lightly and start preparing for a release.

I’m off for vacation for just a week without any internet access (Oh my good, I will hate my inbox). This break will give me some time for my wife and my daughter before my second daughter will arrive in this world which is scheduled for mid june.
If there anything strange happen with my packages, just feel free for a 0day NMU.
Just after this week, I will attend to RIPE 56 where my latency will just a bit lower than normal.

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.

There’s been some controversy generated over my use of the terminology of “Organic” and “Non-Organic” Open Source. Asa Dotzler noted that it wasn’t Mozilla’s original intent to “make a distinction between how Mozilla does open source and how others do open source”. Nessance complained that he didn’t like the term “Non-Organic”, because it was “raw and vague - is it alien, poison, silicon-based?” and suggested instead the term “Synthetic Open Source”, referencing a paper by Siobh n O Mahony, ” What makes a project open source? Migrating from organic to synthetic communities”. Nessance referenced a series of questions and answers by Stephen O’ Grady from Red Monk, where he claimed the distinction between the two doesn’t matter. (Although given that Sun is a paying customer of Red Monk, Stephen admits that this might have influenced his thinking and so he might be “brainwashed” :-). So let’s take some of these issues in reverse order. Does the distinction matter? After all, if the distinction doesn’t matter, then there’s no reason to create or define specialized terminology to describe the difference. Certainly, Brian Aker, a senior technologist from MySQL, thinks it does, as do folks like me and Amanda McPherson and Mike Dolan; but does it really? Are we just saying that because we want to take a cheap shot at Sun? Well, to answer that, let’s go back and ask the question, “Why is Open Source a good thing in the first place?” It’s gotten to the point where people just assume that it’s a good thing, because everybody says it is. But if we go back to first principals maybe it will become much clearer why this dinction is so important. Consider the Apache web server; it was able to completely dominate the web server market, easily besting all of its proprietary competitors, including the super-deep-pocketed Microsoft. Why? It won because a large number of volunteers were able to collaborate together to create a very fully featured product, using a “stone soup” model where each developer “scratched their own itch”. Many, if not most, of these volunteers were compensated by their employers for their work. Since their employers were not in the web server business, but instead needed a web server as means (a critical means, to be sure) to pursue their business, there was no economic reason not to let their engineers contribute their improvements back to the Apache project. Indeed, it was cheaper to let their engineers work on Apache collaboratively than it was to purchase a product that would be less suited for their needs. In other words, it was a collective “build vs. buy” decision, with the twist that because a large number of companies were involved in the collaboration, it was far, far cheaper than the traditional “build” option. This is a powerful model, and the fact that Sun originally asked Roy Felding from the Apache Foundation to assist in forming the Solaris community indicates that at least some people in Sun appreciated why this was so important. There are other benefits of having code released under the Open Source license, such as the ability for others to see the implementation details of your operating system — but in truth, Sun had already made the Source Code for Solaris available for a nominal fee years before. And, of course, there are plenty of arguments over the exact licensing terms that should be used, such as GPLv2, GPLv3, CDDL, the CPL, MPL, etc., but sometimes those arguments can be a distraction from the central issue. While the legal issues that arise from the choice of license are important, at the end of the day, the most crucial issue is the development community. It is the strength and the diversity of the development community which is the best indicator for the health and the well-being of an Open Source project. But what about end-users, I hear people cry? End users are important, to the extent that they provide ego-strokes to the developers, and to the extent that they provide testing and bug reports to the developers, and to the extent that they provide an economic justification to companies who employ open source developers to continue to do so. But ultimately, the effects of end-users on an open source project is only in a very indirect way. Moreover, if you ask commercial end users what they value about Open Source, a survey by Computer Economics indicated that the number one reason why customers valued open source was “reduced dependence on software vendors”, which end users valued 2 to 1 over “lower total cost of ownership”. (Which is why Sun Salescritters who were sending around TCO analysis comparing 24×7 phone support form Red Hat with Support-by-email from Sun totally missed the point.) What’s important to commercial end users is that they be able to avoid the effects of vendor lock-in, which implies that if all of the developers are employed by one vendor, it doesn’t provide the value the end users were looking for. This is why whether a project’s developers are dominated by employees from a single company is so important. The license under which the code is released is merely just the outward trappings of an open source project. What’s really critical is the extent to which the development costs are shared across a vast global community of developers who have many different means of support. This saves costs to the companies who are using a product being developed in such a fashion; it gives choice to customers about whether they can get their support from company A or company B; programmers who don’t like the way things are going at one company have an easier time changing jobs while still working on the same project; it’s a win-win-win scenario. In contrast, if a project decides to release its code under an open source license, but nearly all the developers remain employed by a single company, it doesn’t really change the dynamic compared to when the project was previously under a closed-source license. It is a necessary but not sufficient step towards attracting outside contributors, and eventually migrating towards having a true open source development community. But if those further steps are not taken, the hopes that users will think that some project is “cool” because it is under an open-source license will ultimately be in vain. The “Generation Y”/Millennial Generation in particular are very sensitive indeed to Astroturfing-style marketing tactics. Ok, so this is why the distinction matters. Given that it does, what terms shall we use? I still like “Organic” vs “Non-organic”. While it may not have been intended by the Mozilla Foundation, the description in their web page, “only a small percentage of whom are actual employees [of the Mozilla Foundation]“, is very much what I and others have been trying to describe. And while I originally used the description “Projects which have an Open Source Development Community” vs “Projects with an Open Source License but which are dominated by employees from a single company”, I think we can all agree these are very awkward. We need a better shorthand. When Brian Aker from MySQL suggested “Organic” vs “Non-Organic” Open Source, and I think those terms work well. If some folks think that “Non-Organic” is somehow pejorative (hey, at least we didn’t say “genetically modified Open Source” :-), I suppose we could use Synthetic Open Source. I’m not really convinced that is any much more appetizing, myself, however. So what would be better terms to use? Please give me some suggestions, and maybe we can come up with a better set of words that everyone is happy with.

There’s been some controversy generated over my use of the terminology of “Organic” and “Non-Organic” Open Source. Asa Dotzler noted that it wasn’t Mozilla’s original intent to “make a distinction between how Mozilla does open source and how others do open source”. Nessance complained that he didn’t like the term “Non-Organic”, because it was “raw and vague - is it alien, poison, silicon-based?” and suggested instead the term “Synthetic Open Source”, referencing a paper by Siobh n O Mahony, ” What makes a project open source? Migrating from organic to synthetic communities”. Nessance referenced a series of questions and answers by Stephen O’ Grady from Red Monk, where he claimed the distinction between the two doesn’t matter. (Although given that Sun is a paying customer of Red Monk, Stephen admits that this might have influenced his thinking and so he might be “brainwashed” :-). So let’s take some of these issues in reverse order. Does the distinction matter? After all, if the distinction doesn’t matter, then there’s no reason to create or define specialized terminology to describe the difference. Certainly, Brian Aker, a senior technologist from MySQL, thinks it does, as do folks like me and Amanda McPherson and Mike Dolan; but does it really? Are we just saying that because we want to take a cheap shot at Sun? Well, to answer that, let’s go back and ask the question, “Why is Open Source a good thing in the first place?” It’s gotten to the point where people just assume that it’s a good thing, because everybody says it is. But if we go back to first principals maybe it will become much clearer why this dinction is so important. Consider the Apache web server; it was able to completely dominate the web server market, easily besting all of its proprietary competitors, including the super-deep-pocketed Microsoft. Why? It won because a large number of volunteers were able to collaborate together to create a very fully featured product, using a “stone soup” model where each developer “scratched their own itch”. Many, if not most, of these volunteers were compensated by their employers for their work. Since their employers were not in the web server business, but instead needed a web server as means (a critical means, to be sure) to pursue their business, there was no economic reason not to let their engineers contribute their improvements back to the Apache project. Indeed, it was cheaper to let their engineers work on Apache collaboratively than it was to purchase a product that would be less suited for their needs. In other words, it was a collective “build vs. buy” decision, with the twist that because a large number of companies were involved in the collaboration, it was far, far cheaper than the traditional “build” option. This is a powerful model, and the fact that Sun originally asked Roy Felding from the Apache Foundation to assist in forming the Solaris community indicates that at least some people in Sun appreciated why this was so important. There are other benefits of having code released under the Open Source license, such as the ability for others to see the implementation details of your operating system — but in truth, Sun had already made the Source Code for Solaris available for a nominal fee years before. And, of course, there are plenty of arguments over the exact licensing terms that should be used, such as GPLv2, GPLv3, CDDL, the CPL, MPL, etc., but sometimes those arguments can be a distraction from the central issue. While the legal issues that arise from the choice of license are important, at the end of the day, the most crucial issue is the development community. It is the strength and the diversity of the development community which is the best indicator for the health and the well-being of an Open Source project. But what about end-users, I hear people cry? End users are important, to the extent that they provide ego-strokes to the developers, and to the extent that they provide testing and bug reports to the developers, and to the extent that they provide an economic justification to companies who employ open source developers to continue to do so. But ultimately, the effects of end-users on an open source project is only in a very indirect way. Moreover, if you ask commercial end users what they value about Open Source, a survey by Computer Economics indicated that the number one reason why customers valued open source was “reduced dependence on software vendors”, which end users valued 2 to 1 over “lower total cost of ownership”. (Which is why Sun Salescritters who were sending around TCO analysis comparing 24×7 phone support form Red Hat with Support-by-email from Sun totally missed the point.) What’s important to commercial end users is that they be able to avoid the effects of vendor lock-in, which implies that if all of the developers are employed by one vendor, it doesn’t provide the value the end users were looking for. This is why whether a project’s developers are dominated by employees from a single company is so important. The license under which the code is released is merely just the outward trappings of an open source project. What’s really critical is the extent to which the development costs are shared across a vast global community of developers who have many different means of support. This saves costs to the companies who are using a product being developed in such a fashion; it gives choice to customers about whether they can get their support from company A or company B; programmers who don’t like the way things are going at one company have an easier time changing jobs while still working on the same project; it’s a win-win-win scenario. In contrast, if a project decides to release its code under an open source license, but nearly all the developers remain employed by a single company, it doesn’t really change the dynamic compared to when the project was previously under a closed-source license. It is a necessary but not sufficient step towards attracting outside contributors, and eventually migrating towards having a true open source development community. But if those further steps are not taken, the hopes that users will think that some project is “cool” because it is under an open-source license will ultimately be in vain. The “Generation Y”/Millennial Generation in particular are very sensitive indeed to Astroturfing-style marketing tactics. Ok, so this is why the distinction matters. Given that it does, what terms shall we use? I still like “Organic” vs “Non-organic”. While it may not have been intended by the Mozilla Foundation, the description in their web page, “only a small percentage of whom are actual employees [of the Mozilla Foundation]“, is very much what I and others have been trying to describe. And while I originally used the description “Projects which have an Open Source Development Community” vs “Projects with an Open Source License but which are dominated by employees from a single company”, I think we can all agree these are very awkward. We need a better shorthand. When Brian Aker from MySQL suggested “Organic” vs “Non-Organic” Open Source, and I think those terms work well. If some folks think that “Non-Organic” is somehow pejorative (hey, at least we didn’t say “genetically modified Open Source” :-), I suppose we could use Synthetic Open Source. I’m not really convinced that is any much more appetizing, myself, however. So what would be better terms to use? Please give me some suggestions, and maybe we can come up with a better set of words that everyone is happy with.

Till today I thought make was a very simple concept, but looking at other people's debian/rules files I start to lose that faith. So let's begin with some basics (as I guess many reading this are maintainers for Debian packages, and you might need some of this knowledge): As you will already know, the most important part of a Makefile is a rule. Each rule is there to produce something and has prerequisites, i.e. things that have to be done before. So far so simple. When you think about this way, the first pitfall is already no pitfall anymore:

   build: patch build-indep
   build-indep: build-indep-stamp
   build-indep-stamp:
   	$(MAKE) doc
   	touch build-indep-stamp
   

There are two mistakes in this. First of all, the clean is only called on ./debian/rules build, but not on ./debian/rules build-indep. And then patch is only called by the build target. But what you really want is that the source is patched before you do something, so it is something do be done before build-indep-stamp. The pitfall with this error is that you will not see it most of the time. As make usually processes targets in the order it finds them, it usually runs patch first. Except when you have multiple processors and tell make to make sure of them (and even then there is a chance it might work as the command to run first is fast enough) or if someone trusting on what he learned about make does call ./debian/rules build-indep-stamp build. I guess a reason one sees this so often is the next pitfall. Most likely previous the following was tried:

   build-indep: build-indep-stamp
   build-indep-stamp: patch
   	$(MAKE) doc
   	touch build-indep-stamp
   patch: patch-stamp
   patch-stamp:
   	whatever
   	touch patch-stamp
   

The pitfall with this is some new concept. The problem is that the patch rule is phony. A rule is called phony when it does not produce the target it claims to do. The classical example is a clean target. You do not want that a clean target creates a file clean and the next time it is called says "already everything done". Targets get phony by telling make it is (via .PHONY:) or by just not producing the file it tells to produce or (suprising to many, it seems) by having a phony target as prerequisite. In the above example the patch target gets implicitly phony, as it does not produce a file called patch. Thus after having build the source and calling binary to create packages, this will most likely in some way depend on build-indep-stamp. But when make thus looks at build-indep-stamp to decide if it already there and even though it sees the file produces there with the touch command, it cannot determine if that is up to date. It depends on patch and there is no file called this, thus make must assume it is not up to date, thus build-indep-stamp has become effectively also phony, in the sense of having to be called every time it is depended on. (In case you have not noticed, the fix would have been to make build-indep-stamp depend on patch-stamp instead or to go without patch-stamp and make patch the file to be generated). Thus, you can put as many -stamp files as you want in a row, as long as you have a single phony prerequisite in them, it is all void.

Any ALSA experts around that can help me with the following setup?I want to create a virtual device that does the following: - send the audio data to my regular onboard sound devices - when I plug in some USB audio device, send it there as well OR just thereThe difficult part is the plugging part. There is an example in the Wiki how to use two cards as one. This works, but only if the USB audio device was plugged in before starting the audio application and it is not unplugged either.Obviously, switching the configuration files on plug events is another possibility, but again this requires applications to be restarted. :-(What I want to achieve is simple: when I plug in the USB device, I want to switch my music playback there (since it will be connected to my stereo). System events, voice calls etc. however should remain on the system audio.If you have any solution, please send me an email at erich AT debian DOT org.(And yes, I know about PulseAudio, and I use it. But only on top of ALSA)