Lucas has written two long, insightful posts on the frustration about the social aspects of integrating Ruby stuff Debian The first one, on September 12 and the second one, on September 29. I cannot really blame (thoroughly) the Ruby guys for their position. After all, they have a vibrant community, and they are advancing great pieces of work. And they know who that code is meant for Fellow programmers. And yes, although it is a pain to follow their API changes (and several of the Gems I regularly use do often get refactorings and functionality enhancements which break compatibility but introduce very nice new features), they say that's solved with one of Gems' main features being the simultaneous installability of different versions. The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers. Even leaving aside heaps of different positions and worldview/mindset, we have a fundamental difference: Debian cares about its users, whatever that means. So, our users should not even care what language a given application is implemented in They should only care that it works. We, as packagers, should take care of all the infrastructural stuff. And yes, that's where we find the conflicting spot: We don't want to ship many versions of a system library (that in this case would be a Gem). Specially if later versions fix known bugs in earlier versions and backports are not available or supported. Specially if upstream authors' only response to a bug in an older release will be "upgrade and rewrite whatever breaks in your application". As an example of this, I am not currently updating the gems I maintain, as Debian is on a freeze to get out the next stable release. Or if at all, I am targetting those uploads to our Experimental branch, in order not to create a huge backlog for me when the freeze is over (just a series of rebuilds targetted at unstable). And yes, I will have to be responsible for any bugs that will most likely not be supported by most of my upstreams during the next ~2 years. That's the role of a Linux distribution. And yes, as Lucas writes in the comments he got as responses to the first post This dissonance comes in no small part because the Ruby developer community is mostly made from non-linuxers. People coming from a background where (mostly propietary) applications bundle up everything they need, where static linking is more popular than dynamic libraries, where there is no coordination between parts of the system are much less likely to understand our work. And yes, the Perl community is a joy to work with in this regard. And that's the same I understand from the Python one. Because of their origins and where their main strength was grown and remains. PS - And yes, I will join the flock of people saying that... The specific person that attacked your work is a great programmer, but well known as intolerant and obnoxious. Fortunately, even if our respective cultures fail to mix so much, most of our interactions just end with a "sigh" of lack of understanding, and not with the flames you got targetted with :-/

In my Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ, I wrote The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable). Zed A. Shaw just provided a very good example of that. Quoting the most juicy parts:

It s simply a tactic to make sure that you are stuck on Debian.

If we look at this problem from an open source perspective, Debian is at a minimum being a horrible citizen.

What is happening is control is not aligned with responsibility. Debian has taken control of the software package and recrafted it for their very narrow set of system administrator users. However, they refuse to take responsibility for the defect and quality problems they create. Instead I end up being responsible for their mistakes, which is wrong.

If Debian is in control, then Debian should be made responsible. That s the only way to get them to change it. If they don t want to be responsible, then they should let me be in control.

I m imagining a mass petition, maybe some funny ad campaigns, in-person confrontations meant to embarrass package maintainers, SEO tricks to get people off Debian, promotion of any alternative to Debian, anything to make them pay, apologize, and listen.

If you write software and you re sick of Debian screwing up your gear, then shoot me ideas for how we can make this happen. I think that if enough of us band together to make Debian responsible for its actions we can actually get them to start asking us before they package our software to find out how we think it should be packaged.

On the technical part of the post: The problem that Zed is experiencing is unknown to me, and also to the Debian and Ubuntu bug trackers. To my knowledge, rubygems doesn t not require openssl or net/scp to work, and a simple grep through the sources kind-of confirms that. But of course, that blog post was written as a rant, not as a proper bug report. My best guess is that the gem that Zed is installing requires openssl and net/scp. But of course, rubygems can t just depend on all the libraries that applications or libraries installed via rubygems could possibly require. Regarding openssl, we had a problem in Ruby because of the licensing situation of Ruby (dual licensed GPLv2+ and Ruby license, linked with openssl, which might raise some eyebrows), so it was split off the main standard library package until recently (and, apparently, in the version Zed is using). For net/scp, it is not part of the standard library, and not a dependency of rubygems, so I don t see why Zed expects it to be installed. On the rest of the post: Following my last post, several people volunteered to help with Ruby on Debian (and Ubuntu). In particular, Laurent Arnoud has been doing some fantastic work fixing the pkg-ruby-extras team s RC bugs. Also, all the messages of support both in the comments of my last post were very much appreciated. But I m really wondering why the Ruby community generates so many poisonous people. All my work on Debian is done on a volunteer basis, and it s really hard to get so much shit from it.

Can you believe it? I still talk to people who don t know how to play blackjack. There must be something in the mechanics or tableau of blackjack that people find intimidating; for some reason, people can be a little cautious about taking the first move.
Photo courtesy of Winquerque on Net via Flickr. Clearly, there s no cause to hesitate. Players find quite quickly that it is actually not hard to figure out, and the strategies aren t even terribly complicated. For sure, if you re used to playing online slots, you are probably going to need to work a little harder to master the nuts and bolts. But it s still nothing like getting to grips with Texas Hold em from the beginning, for example!. Quite frankly, you very likely already know a fair portion of what most players have to know. I am able to give you the essentials in one simple little paragraph: If the card has aparticular number, that s the amount it will be worth. If it doesn t, it s worth 10. The only exception to this rule are Aces, which are worth either 1 or 11 (more about that later). Say hit when you have to get closer to 21, and/or stand when you don t. If you are closest to 21, you win. If you bust (get more than 21), you lose. Getting dealt blackjack (a natural 21 from the first two cards), makes you an instant winner (well, you and the dealer can also tie, or push ). Got it? OK, so it is not completely all you need to know. To begin with, most professional blackjack fans understand all too well that your goal has less to do with trying to get to 21, and just about everything to do with defeating an opponent. The dealer will not have the luxury of actually playing , precisely. Whether you re playing at a land-based casino or online (speaking of which, for additional info on USA casino players, all you have to do is click the link!), the house rules specify each individual play they can make. Mainly, she or he needs to take another card until their cards add up to the house rule limit (generally 17 and over). Of course, one of you will get an ill-fated draw and find themselves busted , but this decides a fewer number of games than you might expect. The tricky aspect of blackjack is the decision that you have to make if the cards add up somewhere around 12 and 16 (approximately, subject to other details). If you only had your own cards to consider, it would just be nothing but chance. Don t get me wrong, dumb luck has quite a lot to do with it. It is a card game, of course, and all card games are based on luck to some extent. But the serious gamer recognizes that luck is essentially a code word for statistics ; if you know what you have, and you possess a clue about the dealer s cards, you may make a knowledgeable judgment about which cards you re more inclined to end up with if you decide to hit another time. The most useful clue that you require to evaluate whether to play risky or conservative (sorry, I meant loose or tight ) is the dealer s upcard. Well, that s all for now, but for more information, you can always take a look at our friends at USA online casinos accepting Webmoney , who will get you up to speed. A bit later, we re going to get down to the serious nitty-gritty: doubling down, splitting, and much much more. Until then !

Daily builds As of a month ago there are Ubuntu archives with fresh packages of Samba 4 and Openchange, built on a daily basis day from the latest upstream revision. This means that it is now possible to run a version of Samba 4 that is less than 24 hours old, without having to know how to extract source code from the version control system that upstream is using, without having to know how to build and install an application from source, but perhaps most importantly: without having to go through the tedious process of manually updating the source code and rebuilding. OpenChange is tightly coupled to Samba 4, so installing a new version of OpenChange usually involves installing a new version of Samba 4 as well. To make matters more confusing, the two projects use different version control systems (Samba 4 is in Git, while OpenChange is in Subversion) and different build systems (Samba 4 uses waf, OpenChange uses autoconf and make). I have been involved in Samba 4 and OpenChange as an upstream developer and more recently also as a packager for both Debian and Ubuntu. As an upstream developer for both these projects it is important for me that users can easily run the development versions. It makes it possible for interested users to confirm the fixes for issues they have reported and to test new features. The more users run the development version, the more confident I can be as a developer that doing a release will not cause any unexpected surprises. As a packager it is useful to know when there are upstream changes that are going to break my package with the next release.

Recipes The daily builds work using so-called recipes which describe how to build a Debian source package from a set of Bazaar branches. For example, the Samba 4 recipe looks like this:

# bzr-builder format 0.2 deb-version 4.0.0~alpha14~bzr revno ~ppa revno:packaging + revno:debian 
lp:samba
merge debian lp:~samba-team/samba/unstable
merge packaging lp:~samba-team/samba/4.0-ppa-maverick

This dictates that a source package should be built by taking the upstream Samba branch and merging the Debian packaging and some recipe-specific tweaking. The last bit on the first line indicates the version string to be used when generating a changelog entry for the daily build. Every night Launchpad (through bzr-builder) merges these branches and attempts to build the resulting source package, e-mailing me in case of build problems. Generally I fix issues that come up by committing directly to upstream VCS or to the Debian packaging branch. There is no overhead in maintaining the daily build after I've set it up. For more information on creating source package recipes, see getting started.

Toolchain The entire toolchain that does the daily package builds for Ubuntu is Free Software, and I have contributed to various bits of that toolchain over the years. It's exciting to see everything come together.

Soyuz Launchpad consists of multiple pillars - one of those pillars is Soyuz, which I hack on as part of my day job at Canonical. Soyuz is responsible for the archive management and package building. Debian source packages (a combination of upstream source code and packaging metadata) get uploaded by users and then built for various architectures on our buildfarm and published to the Ubuntu archive or to users personal package archives.

Launchpad-code Another pillar of Launchpad is Launchpad-code, which is responsible for the hosting and management of version control branches. Launchpad users can either host their branches on Launchpad directly or mirror branches (either native Bazaar branches or branches in a foreign format such as Subversion, Git or Mercurial). The mirrorring of native and foreign branches happens using standard Bazaar API's. In the case of Samba and OpenChange we import the branches of the upstream projects (Samba is in Git, OpenChange is in Subversion) and the packaging for both projects is in Bazaar. Launchad-code calls out to Bazaar to do the actual mirrorring. Over the last few years I have done a lot of work to improve Bazaars support for foreign branches, in particular on supporting Subversion, Git and Mercurial. As the code mirrorring in Launchpad is one of the biggest users of bzr-svn and bzr-git it has helped find some of the more obscure bugs in those plugins over the last few years, to the point where there are only a handful of issues with Git and Subversion imports left.

bzr-git and dulwich bzr-git provides transparent access to Git repositories from within Bazaar and is built on top of Dulwich. Dulwich is a Python library that provides access to the Git file formats and protocols that is completely independent of Bazaar. James Westby originally started it and I adopted it for bzr-git and further extended it. There are now several other projects that use it as well, including hg-git, and rabbitvcs. Apart from James and me almost two dozen other people have contributed it so far.

bzr-svn and subvertpy bzr-svn provides transparant access to Subversion repositories in Bazaar. When I grew frustrated with the existing Subversion Python bindings for various reasons, I decided to create independent Python bindings for Subversion from scratch. These bindings have since been split out into a separate project - subvertpy - and other projects have since also started using them, e.g. hgsubversion and basie.

Using the daily builds To use the Samba 4 and OpenChange daily builds (Ubuntu Maverick only for now), run:

$ apt-add-repository ppa:samba-team/ppa
$ apt-add-repository ppa:openchange/daily-builds

cp: Karnivool - Themata

There are situations in which a given package needs to have different dependencies in Debian and in Ubuntu. Despite this difference it s possible to keep a single source package that will build both variants of the package. Continue reading to discover a step-by-step explanation. 1. When is that needed? While it is possible to have different dependencies depending on the distribution on which the package is built, it should be usually avoided when possible. This infrastructure should only be used as a last resort when there are no better alternatives. Here are some examples of when it might be needed:

• Ubuntu has some packages that Debian does not have (or vice-versa), and the resulting package would benefit from having them installed.
• The package names differ between Ubuntu and Debian and it s on purpose (i.e. the difference is a justified choice and not a mistake because both distributions failed to coordinate).
• The packages are built differently in both distributions, and the run time dependencies are not the same due to this. Maybe some associated patches are only applied in Ubuntu.

2. Using substitution variables in debian/control The dependency that varies between both distributions can t be hardcoded in debian/control, instead you should put a substitution variable (substvar) that will be replaced at build time by dpkg-gencontrol. You can name it $ dist:Depends for example:

[...]
Depends: bzip2, $ shlibs:Depends , $ misc:Depends , $ dist:Depends 
[...]

Note that you typically already have other substitution variables ($ shlibs:Depends comes from dpkg-shlibdeps and $ misc:Depends from debhelper and its dh_* scripts). 3. dpkg-gencontrol needs a -V option The value used to replace this new variable needs to be communicated to dpkg-gencontrol. You can use the -V option for this, the syntax would be something like this:

dpkg-gencontrol [...] -Vdist:Depends="foo (>= 2), bar"

If you use debhelper, you have to pass the option to dh_gencontrol after two dashes (--):

dh_gencontrol -- -Vdist:Depends="foo (>= 2), bar"

If you use CDBS, you can set the DEB_DH_GENCONTROL_ARGS_ALL make variable:

include /usr/share/cdbs/1/rules/debhelper.mk
DEB_DH_GENCONTROL_ARGS_ALL = -Vdist:Depends="foo (>= 2), bar"

The value given to dpkg-gencontrol is static in all those examples, now let s see how we can use give a different value depending on the distribution that we re targetting. 4. Using dpkg-vendor in debian/rules dpkg-vendor is a small tool (provided by the dpkg-dev package) that parses the /etc/dpkg/origins/default file (provided by the base-files package) to know the current distribution and its ancestry. It can be used in debian/rules to adjust the behavior depending on the current distribution. You can check its man-page to learn about the various options supported but we re only going to use --derives-from <vendor> in this sample. With this option the script exits with zero if the current distribution is or derives from the indicated distribution, or with 1 otherwise. Now combining all together, we can use dpkg-vendor to dynamically define the content of the substitution variable in debian/rules. Let s suppose that you want $ dist:Depends to be foo (>= 2) on Ubuntu (and its derivatives) and bar everywhere else. Using debhelper s 7 tiny rules file, this example could be:

ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
	SUBSTVARS = -Vdist:Depends="foo (>= 2)"
else
	SUBSTVARS = -Vdist:Depends="bar"
endif
%:
	dh $@
override_dh_gencontrol:
	dh_gencontrol -- $(SUBSTVARS)

If you use CDBS, it could be this:

include /usr/share/cdbs/1/rules/debhelper.mk
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
	DEB_DH_GENCONTROL_ARGS_ALL = -Vdist:Depends="foo (>= 2)"
else
	DEB_DH_GENCONTROL_ARGS_ALL = -Vdist:Depends="bar"
endif

Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.

9 comments Support my work

Working on a new feature for eSpeak GUI I started looking into language identification. Forcing users to manually choose the text s language is a botheration, so trying to guess it by checking which system dictionary contains the most words from the text or some other method would surely be beneficial. After a quick search I learned that it s much easier than this: it s possible to reliably determine the language based on statistic n-gram information. Ignoring the fact that now I officially hate Firefox, Chromium, OpenOffice.org and everyone else there for not implementing this and having me spend the day changing the spell-checker s language, I was left with the choice on how to use this in eSpeak GUI. The first option I found was TextCat, which is also the only library I ve found to be packaged for Debian. However, ignoring the fact that upstream isn t maintaining it any more (such a library shouldn t need too much maintainance, after all), the package declares incorrect dependencies (bug filled a month ago, no response yet) and the API is also pretty crappy (it requires a physical file indicating the location of the statistic models). Unrelated to that, I ve also found that the Catalan text samples it includes are incorrect, so the same may be true for other languages. I guess it d make sense to work on a new (and completely Unicode) language samples collection. I ve thought of using something like the Universal Declaration of Human Rights since this way all languages can have the same text, but being more of a legal thing it may be biased by some words being too repetitive. Looking for other alternatives to the TextCat library I ve only found the following:

• TextCat (same name, different code): PHP licensed, so incompatible with GPL projects.
• Mguesser (part of mnogosearch-mysql): it s a standalone executable and not a library.
• SpamAssassin s TextCat.pm: also a standalone executable, this time written in Perl. Apparently they were using a fork of TextCat (the original library, not the PHP licensed one) before that.

So it looks like I ll have to start by getting a good collection of text samples I can use to generate the statistic data. Then I have several options on how to actually use it. As I see it, those are my possibilities:

1. Fixing libtextcat s packaging and just using that.
2. Taking it over as new upstream maintainer. Not my preferred option as I don t really feel like maintaining a C library at this point.
3. Trying to convince the maintainer of the new TextCat (with last commit January this year and a more sane API) to re-license it in a GPL-compatible way, packaging that and seeing how that one works (haven t tried it out yet).
4. Writing my own implementation in Python, maybe based upon this example or TextCat.pm.

Any other ideas, pointers to some library I may have missed or offers to collaborate are very welcome. Please also note that my intention in writing this post is not only to rant about there being no well-maintained ready-to-use library being available, but especially raising awareness on the topic of language identification. I d love to see this feature all around the desktop, just like (and in combination with) spell-checking, which is already omnipresent. Related posts:

1. espeak-gui 0.2
2. Introducing espeak-gui

---

11 comments
Siegfried-Angel Gevatter Pujals, 2010. Permalink License Post tags: language identification, Programari lliure, text categorization

As I'm currently attending the EUgridPMA meeting in Zagreb I thought I'd share a bit of this project I've been working on for the past year: the TCS eScience project. In the scientific world lots of calculations are performed on distributed computing platforms known as grid. Because users of other institutions will be using your hardware, authentication is needed and this problem has been solved with x.509 personal certificates. The problem however, is that these certificates of course have to be issued by some CA. Currently in Europe alone there are over 40 active CA's, even multiple per country, dedicated to this job. They are accredited through the EUgridPMA which meets regularly. For scientists, it's often cumbersome to obtain a certificate: find your local CA, present an ID (probably in person), and sometime later receive your certificate. The process can take days or even weeks. Scientists are not interested in CA's but just want to practice science. Our solution is a central web portal where users can request a certificate and have it delivered in minutes. This leverages the fact that identities of scientists normally have already been vetted at their home institution: users log in to the portal via federated login. Their home institution passes a special attribute that declares "Yes, we have really seen photo ID of this person and the name is correct". This attribute must of course not be passed for guests or test users or role accounts. However, it may still be easy to mass-provision it. In the Netherlands for example, the employer is required by law to verify the identity of each employee, so all employees can be automatically assigned the attribute. After logging in and uploading (or generating) a csr, the request is passed in the back end to the Comodo API. This also means that we do not need to perform the complex operations of running an online CA (with hardware crypto devices, crl's, etc.). The use of Comodo is part of the same deal as the TERENA Certificate Service for host SSL certificates. The Comodo API responds within two minutes with the certificate which the user can download. Currently 10 European countries are involved with the project (nl no se fi dk at cz it fr be), and more have shown interest. The certificates we issue have been accredited by the EUgridPMA so can be used on the grid. A separate but similar service is being set up for 'regular' personal certificates for the academic community, e.g. for s/mime usage. More details are in the presentation and paper by portal software developers Henrik and Thomas at the most recent TNC.

When I was a child, an Xmas tradition in our house was that the whole family would play Monopoly. It was a fun game, even though my father would always win. It seems they played it so much in his childhood that he still remembered all the rules and cards and prices and so on by heart, thirty years later. Me, I wouldn't remember what I did yesterday, if I didn't have my ikiwiki-powered journal. Anyway, in a random discussion with my SO, we thought of some variants to the rules that might make it more interesting to adults. First, introduce a legal system, with lawyers, law suits, judges, etc. For example, if you don't want to pay your bill, sue the landlord for something. This would give some time to go on with other activities. The winner is the person who first throws a double, and the loser pays 1d6 times the original amount. (Exact rules to be determined by playtesting, of course.) Then introduce a political system into the game. Let players or bystanders be elected into a parliament, which gets to invent new rules. And finally, allow politicians and judges to be bribed. Corruption is rampant in the real world, so it should not be missing from Monopoly, either.

This is a guest post by Michael Schultheiss, DebConf10 travel sponsorship team lead.DebConf doesn't just provide sponsored food and accommodation to attendees, it can also provide travel reimbursement to 20-30 attendees each year, from all over the world.The travel sponsorship team has historically been formed by a call to debian-devel-announce for developers to review sponsorship requests. This has resulted in one of the most transparent review teams of DebConf, which is by design since this is one of the hardest decisions to make. A team of about ten people will review applications. The travel sponsorship team is typically comprised of both people with past travel sponsorship team experience as well as new members to help make the process as fair as possible. The team will consider the listed workplans, the answer to the question "what do you do for Debian", their general knowledge of Debian contributors, and web searches of Debian lists, debian.org, and the web in general, looking for Debian and free software related activities.Applicants are rated on a 1-5 scale of contributor level and amount requested. These are averaged and sorted, and this is used as the basis of travel sponsorship - but is subject to human review for special cases. The team will then decide the cutoffs for the different queues - for example, DebConf10 used queue A which had money released first, queue B which was released after more fundraising, and queue C which was told "no". After these queues are decided, most of the selection team doesn't need to be as active, but anyone from that team can work with the organizers to decide percentages of funding of the queues and when to commit money to them, based on our budget.Attendees submit documentation for actual flight costs after the conference, and can be reimbursed for min(actual_costs, amount_requested).There are various problems with this system, which are pretty well known but not so easy to fix:

• Attendees are supposed to put the amounts they can't afford to pay themselves, but we have no way of checking this (and probably wouldn't want to pry so much to be able to...)
• Historically, money has been budgeted for travel sponsorship last, thus travel sponsorship usually isn't confirmed until late in the process. This means that flight prices have constantly gone up, and some people may be unable to attend DebConf due to uncertainty over travel sponsorship.
• Attendees have a dilemma: They are supposed to enter only the amount they cannot fund themselves. But if there is a chance of fares being reimbursed at less the requested amount, then entering the amount absolutely required to attend results in a disadvantage.
• Invariably, people get confuse "amount I am unable to afford" as "amount I am able to afford"
• For some years, entering too high a requested sponsorship amount could result in a lower priority - instead of the selection team adjusting the amount downward. Thus, attendees have another dilemma about what to request.

These questions are hard to answer. I'm encouraged that there are some discussions on debconf-team which are working towards a better system. Most importantly, these people want to start early, which is almost guaranteed to result in a better outcome for everyone. If you are interested in working to improve the travel sponsorship process, I encourage you to get involved in the team and start early.Tags: debconf

Apparently, live.com thinks that any browser coming from a ppc architecture is a mobile device. This sucks for the users of the hundreds of thousands of powerpc desktops still in service. I don't use hotmail myself, but i do support people who use it. I set one of my clients up with debian squeeze on their PPC machine because all the proprietary vendors have basically given up on that architecture -- debian represents the best way to get modern tools on these machines (and other machines too, but that's a different argument). However, this client couldn't get to their hotmail account, despite using the latest version of iceweasel (3.5.12). They were directed to a crippled interface that didn't include the ability to attach files, and was a gross waste of the desktop screen space. It appears to be the "mobile" version of live.com's services. However, the same version of iceweasel on an i686 test machine could access the standard version of hotmail with no trouble. My friend jeremyb helpfully suggested fiddling with the User Agent string exported by the browser. Some experimentation shows that the presence of the string "ppc" within any parenthetical expression in the UA makes live.com show the crappy interface. You can try it yourself (if you have a hotmail account) on your x86 or amd64 machine by adding (ppc) to the default valule of general.useragent.extra.firefoxComment in about:config. Stupid stupid stupid. I'd like to have fixed this by overriding the browser's reported architecture (or simply by removing it -- why does a web server need to know the hardware architecture of my client?). But there doesn't appear to be a way to do that with the way that mozilla constructs the UA. Instead, i needed to add a new string key named general.useragent.override which is not exposed by default in about:config. This raises some questions:

• Why are we publishing our hardware architectures from our browsers anyway? This seems like unncessary leakage, and not all browsers do it. For example, Arora doesn't leak this info (despite a poorly-argued request to do so). Browsers are already too identifiable by servers. This information should not be leaked by default.
• Why does live.com insist on sending ppc users to the crappy "mobile" version? Are they trying to encourage the treadmill of hardware upgrades that proprietary vendors benefit from? Is there some less insidious explanation? Are there actually more powerpc-based mobile devices than desktops?
• why is there no simple way to tell Firefox/Iceweasel to override or suppress the architecture information? Having to override the useragent string entirely means that when iceweasel does eventually get upgraded, it's going to report the wrong version unless i can remember to update the override myself (i can't reasonably expect a non-techie client who never heard of user agents before today to remember how to do this correctly).

Any ideas?Tags: browser, hotmail, powerpc, ppc, useragent, wtf

The Debian policy dictates that package upgrades must take care of preserving user changes to configuration files. This article will explain you how most packages ensure this. This is important knowledge for anyone who has to manage upgrades: knowing how it works lets you easily automate most of it and deal correctly with the fallout. How dpkg manages configuration files Most packages rely on dpkg to properly install configuration files. Dpkg keeps a checksum of the last installed version of configuration file. When it must install a new version, it calculates the checksum of the currently installed file and if it doesn t match anymore, it knows that the user has edited the file. In that case, instead of overwriting the configuration file, it asks the user what to do. You probably already have seen those questions, they look like this:

Configuration file  /etc/bash.bashrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N] ?

In this specific example, if you answer Y or I (for yes or install ), dpkg will install the new version of /etc/bash.bashrc but it will also backup the current version in /etc/bash.bashrc.dpkg-old. If you answer N or O (for no or old ), dpkg will install the new version in /etc/bash.bashrc.dpkg-dist and /etc/bash.bashrc is left untouched. The two other answers allow you to examine the differences before taking a decision. Note that if you choose to start a shell, the new version is currently available as /etc/bash.bashrc.dpkg-new (and since Squeeze there are convenient environment variables $DPKG_CONFFILE_OLD and $DPKG_CONFFILE_NEW in case you want to create a custom review script). All configurations files managed by dpkg are called conffiles because that s the name of the field where they are recorded in the dpkg database. You can display the list of conffiles for any package:

$ dpkg --status bash
[...]
Conffiles:
 /etc/skel/.profile ecb6d3479ac3823f1da7f314d871989b
 /etc/skel/.bashrc 2afdd6c53990f2387a7ef9989af0bc07
 /etc/skel/.bash_logout 22bfb8c1dd94b5f3813a2b25da67463f
 /etc/bash.bashrc 5b3c3bc73d236e4e1b6f9b6c1ed5964e
[...]

The command dpkg-query --showformat='$ Conffiles \n' --show bash can give you the same information if you need to retrieve only that field. The 32 characters after the filename are the MD5 checksum of the original configuration file provided by the package. Avoiding the conffile prompt Every time that dpkg must install a new conffile that you have modified (and a removed file is only a particular case of a modified file in dpkg s eyes), it will stop the upgrade and wait your answer. This can be particularly annoying for major upgrades. That s why you can give predefined answers to dpkg with the help of multiple --force-conf* options:

• --force-confold: do not modify the current configuration file, the new version is installed with a .dpkg-dist suffix. With this option alone, even configuration files that you have not modified are left untouched. You need to combine it with --force-confdef to let dpkg overwrite configuration files that you have not modified.
• --force-confnew: always install the new version of the configuration file, the current version is kept in a file with the .dpkg-old suffix.
• --force-confdef: ask dpkg to decide alone when it can and prompt otherwise. This is the default behavior of dpkg and this option is mainly useful in combination with --force-confold.
• --force-confmiss: ask dpkg to install the configuration file if it s currently missing (for example because you have removed the file by mistake).

If you use Apt, you can pass options to dpkg with a command-line like this:

$ apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

You can also make those options permanent by creating /etc/apt/apt.conf.d/local:

Dpkg::Options  
   "--force-confdef";
   "--force-confold";
 

Bringing up the conffile prompt at any time The conffile prompt is only displayed when dpkg detects that the package provides an new version of the conffile. Thus reinstalling the same package will not bring up the prompt. But you can instruct dpkg to ask nevertheless with the --force-confask option. This is a new feature in Debian Squeeze. It will only ask for files that are locally modified.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

4 comments Support my work

In the process of studying for my PhD general examinations this year, I ended up writing summaries about 200 academic books and articles. AcaWiki is a wiki designed to host summaries of academic articles so it seemed like a great place to host these things. Over the last few months, I've uploaded all these summaries. Since I've finished, I've continued to add summaries of other articles as I read them. My summaries tend to be rough. I write them, run them through a spellchecker, and then post them. I don't even reread them before publishing. I hope to improve them as I reread them over time. Of course, because I've uploaded them to wiki, I hope others will add to and improve the summaries as well. AcaWiki uses Semantic Mediawiki and provides nice platform for publishing, editing, and collaboration. Although there are still ways in which the platform can be better, what is needed now is, quite simply, more contributors. I am sad to see that my summaries make up a big chunk of all summaries on the site. So if you are a student, an academic, or anyone else who writes or has written summaries of articles or books or if you might want to do so, you should consider contributing your summaries, in whatever form, to AcaWiki. I've done a little work to help integrate AcaWiki and Zotero which might make things easier. Doctoral students reading for qualifying or general examinations in particular should should consider taking notes and studying with AcaWiki. From the student's perspective, writing summaries can be one of the best way to reflect on and learn a literature. In the process, one can create a great resource for the rest of the world. If a single doctoral student from each of twenty diverse fields of study published summaries of the 200 key articles in their area, AcaWiki would have the critical core of what is most relevant in academia. Help us build it!

And there, another day come and passed, still no real breakage, only some small things here and there. We are doing something wrong, definitely. Ok, granted, providing everyone who has experimental in their sources.list with a free upgrade path due to us suddenly forgetting that apt actually really wants this NotAutomatic: yes flag in the release instead of just looking it up in our database, later on doing the same to all of the backports user (accidently, happens when you have identical codebases), does count enough for a small icecream. But we didn t have anything serious, which is great. Alex finished patching dak rm in a way that we can now actually close all bugs attached to a (source) package we remove and was thinking of enhancing it to actually also be able to close wnpp bugs attached to it (think of O: bugs for example). Mark had design work on g-p-s, which actually is how do we generate packages and sources and how to move the config sanely into a database . Sounds easy, but trust me, it isn t, when you consider all the special cases Debian has. He also jumped in helpfully whenever there was a question around some coding and stuff, at one time turning up with the insanity/genius/younameit code that allows us to transfer even more of dak.conf into the database. This gets us a good way along the way that should end up with a dak.conf consisting of only the database details and nothing else. My job today looked similar like yesterday. Merge code I got, eat, remove lots of values from dak.conf. This weekend besides totally missing out on Baklava, had us change our dak code quite a bit: 46 files changed, 982 insertions(+), 1060 deletions(-). Besides that we do have about 18 points on our meeting notes, a mail going off to one debian lists sometime the next days summarizing it a bit more.

Rant follows. I have upgraded my PC to squeeze this weekend. While this generally worked fine, udev (version 160-1) made my day. As usual I had not read the release notes previously and was hit by

Please upgrade your kernel before or while upgrading udev.

AT YOUR OWN RISK, you can force the installation of this version of udev WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM

dpkg to the rescue:

dpkg -i /var/cache/apt/archives/linux-base_2.6.32-21_all.deb 
dpkg -i /var/cache/apt/archives/linux-image-2.6.32-5-amd64_2.6.32-21_i386.deb  /var/cache/apt/archives/linux-image-2.6-amd64_2.6.32+28_i386.deb 
reboot

Afterwards the upgrade succeded. (For reference: The correct solution would probably have been to run apt-get install linux-image-2.6-amd64 and rebooting, before starting the dist-upgrade.) udev was not finished with me, though, the syntax for udev rules has changed again. ("NAME="%k" is ignored, because it breaks kernel supplied names", "SYSFS = will be removed in a future udev version, please use ATTR =", "BUS= will be removed in a future udev version, please use SUBSYSTEM=", etc.) So I started googling and rewriting my custom rules for USB-sticks and USB cardreader. After many reboots (the only way to test these rules nowadays), thing were still not working. My cardreader is not an exotic but a common one, i.e. it does not report media changes. (The guide for writing udev rules shares this opinion.) Previously I had:

BUS=="scsi", KERNEL=="sd*", SYSFS model =="Compact Flash",SYSFS vendor =="Generic-",NAME all_partitions ="cardreader/cf"

which caused udev to generate /dev/cardreader/cf1, /dev/cardreader/cf2, etc. on bootup (without media present), enabling me to configure /etc/fstab to allow mounting of /dev/cardreader/cf1 without superuser privileges. After googling I ended up with this new rule:

SUBSYSTEMS=="scsi", KERNEL=="sd*", DRIVERS=="sd", ATTRS vendor =="Generic-", ATTRS model =="SD/MMC          ", SYMLINK+="cardreader/sd%n", OPTIONS+="all_partitions"

and while I get ...

argenau:~# ls -l /dev/cardreader/sd
lrwxrwxrwx 1 root root 6 Sep 19 14:42 /dev/cardreader/sd -> ../sdd

... there is still no /dev/cardreader/sd1 (unless I insert a card and run fdisk -l /dev/cardreader/sd as superuser). Looks like OPTIONS+="all_partitions" is ignored. And indeed I find this in udev's changelog:

udev 152
[...]
The option "all_partitions" was removed from udev. This should not be needed for usual hardware. Udev can not safely make assumptions about non-existing partition major/minor numbers, and therefore no longer provide this unreliable and unsafe option.

Joy. Thanks udev for telling me consumer devices have been fixed overnight, USB cardreaders have suddenly started reporting media change events.

Wanted to post this yesterday, but somehow didnt work out, so here we go now Another meeting day passed, another lot of commits into our repository, another day without entirely breaking the system. But wait, one more chance to break it today, maybe we finally manage. :) Yesterday we got volatile sorted out for Squeeze (Lenny stays like it is, seperate). Its now a suite on ftp-master, and we have all the neccessary information and workflow around it defined. At least so far that we can operate the suite, we don t define what gets into it, we just take that from the volatile team (or, I think, in future, from the SRMs) in a kind of textfile similar to how testing works. Besides having Alex unbreak our bts categorize script, Mark fixing up our BYHAND processing and implementing the volatile stuff I mentioned above, we also merged a patchset from Luca that allows us to provide the packages.debian.org service with a tree containing changelogs, copyright files, NEWS.Debian and README.Debian. Metadata basically. Which they extracted in the past, and that was taking up quite a lot of resources. Much easier if we provide it and they just use it. This is now done for both, the main archive as well as the backports archive. As soon as I upgrade the security archive it will also be done there, which should additionally enable packages.debian.org to display those files for all archives (run by FTPMaster). This update is scheduled for the upcoming week, DSA already gave me the needed bits and pieces on a host so I can do it without breaking security during the process. We currently export this metadata set only to the packages.debian.org host. We do want to provide it to more, but I am waiting for a reply from DSA as to which machine I should use for the open access to those files. When I have that reply it should be available for you all. As a sidenote from that: If you need to compute any data that has to do with the Debian archive (information out of source/binary packages or something around it) and if you do that with your own scripts - you are most likely doing it wrong. Talk to us. We might be able to help you extracting the data you need and keep it updated. Recent examples for that are the above changelogs, but also things like the package-file-mapping snapshot uses to easily determine which file belongs to which source/version, but also information like the Maintainers index, the Uploaders index and whatnot. The simple way is - ask us. We are processing a shitload of data, it might not be too complicated to let your set fall out somewhere at the side, but if you never ask you will never find out Today we start working on some internals of dak and will have some more discussion on agenda points like data.debian.org and the git source format. We already had some words on other points, but those are ones which will take a long time more to fix, like generally reworking the internals of our database to enable us having multiple archives with pretty different access levels inside one machine. (Think of security archive on ftpmaster host. You want to ensure embargoed security issues actually stay embargoed until they are released. Means a good set of neccessary changes inside the database to handle this. We have ideas, but getting them implemented will take a bit).

---

And of course we had been out for food too, helps to stay alive. Turkish restaurant. All nice and well - until they told us they have NO BAKLAVA. Args. Suckers. They ruined this year! WAAAAAAAAAAAAAAAAH. I wish them a windows OS for their live! If not worse! (Can it be worse than windows?) ;-)

For a long time I have mainly been reading Twitter with a generic RSS reader (newsbeuter). Recently this stopped working when twitter.com disabled HTTP Basic Auth in preference of using OAuth. Now I can say a lot of good and bad things about OAuth, but to keep a short story short: It doesn t work with generic RSS readers. Instead of getting the RSS feed from a URL, my RSS reader can run a script that prints an RSS feed. So if I could just write a script that does the OAuth dance to convince twitter.com to give me an RSS feed? Perl to the rescue! Or rather CPAN to the rescue: Net::Twitter::Lite have a nice simple example for setting up OAuth with a desktop application. It also provides access to most of Twitters REST API, but no method for retrieving generic URLs. Using some Jedi mind tricks and reading the source I found a private and undocumented method _oauth_authenticated_request which does exactly what I need. It is quite simple:

1. Get my script from gist.github.com/585710 and install the dependencies (Net::Twitter:Lite).
2. Register you own app at dev.twitter.com to get a Consumer Key and Consumer Secret.
3. Run the script once to setup access and get an Access Token and Access Token Secret.
4. Run the script with an RSS feed url as parameter to get the RSS feeds.

Most interesting feed to follow is probably http://api.twitter.com/1/statuses/home_timeline.atom, which show the same as the home page on twitter.com would show you, and http://api.twitter.com/1/statuses/mentions.atom, which shows any tweet that mentions you.

After my last blog post on Ruby in Debian and Ubuntu, I got a few offers for help, which is excellent. So I ve decided to update this wiki page with pointers to the various team resources, and some examples of tasks that newcomers can do. I d like to stress that many pending tasks are really doable by someone not very qualified in Debian packaging. They are not done just because nobody has the time to do them. Some good examples are the libinotify-ruby, libimage-size-ruby, libffi-ruby RC bugs.

I ve been sitting on this one since more than a month. I ve contacted upstream on the 19.08.2010 and the Debian maintainer on the 02.09.2010. No reaction from them till today, and no, my spamfilter does not eat mail ;) Still, I won t tell you the name of the software (but you could easily guess or check ) So let s put the grey hat on and begin ;) Foreword: when I write spam-filter, I mean some DNSBL/SPF/blah filter, not SpamAssassin, crm114 or other content-based filters. common spam-filters There are plenty of spam-filters out there which work after the following schema:

for check in checks:
    if check(mail) == BAD:
        reject(mail)
        break

And the checks often look like this:

def check(mail):
    errors = False
    result = some_magic(mail)
    if not errors: return result
    else: return GOOD

Here some_magic is a function that do the actual checks (DNSBL lookups etc) and which stores possible happened errors in errors. If an error occurred, it s safer to say the mail was good (or at least not bad) than bad. the problem This looks like a sane approach on the first sight: iterate over all checks and execute them until a mail is found to be spam (and the corresponding check did not end up in an error (imagine some weird DNS error for DNSBL or SPF checks here)). But then the author realizes that the errors might be global , like with DNS: when the first check notices that it can t resolve anything (ie. it ran into a DNS timeout three times in a row), the second check (which also utilizes DNS queries) will most probably result in an error too. After this he adds a global counter for DNS errors and skips all the checks that use DNS if this counter is >=3. Great idea , you say, saving resources is good . Bad idea , I say The reason is simple: DNSError != DNSError. Why? The local resolver might be broken, then every DNS query will end up with an error and DNS-based checks should be really disabled. The first three (out of eg. ten) DNSBLs might be down, but that s not a reason to skip the other seven and the SPF check. Etc Now let s assume all configured DNSBLs are working properly, so is the local resolver and the checks are:

checks = [check_HELO, check_SPF, check_DNSBL]

How could one attack this filter? the attack Set up the following zone

spam.example.com IN NS ns1.example.com
spam.example.com IN NS ns2.example.com
spam.example.com IN NS ns3.example.com
spam2.example.com IN MX mx1.spam.example.com
spam2.example.com IN MX mx2.spam.example.com
spam2.example.com IN MX mx3.spam.example.com
spam2.example.com IN MX mx4.spam.example.com
ns1.example.com IN A 10.1.1.1
ns2.example.com IN A 10.2.2.2
ns3.example.com IN A 10.3.3.3

and greet the to-be-spammed-MTA with EHLO client1.spam.example.com
What happens? The spam-filter tries to resolve client1.spam.example.com in check_HELO to check whether the hostname matches the IP-address the connection is coming from, fails three times (there are no reachable DNS servers in 10.0.0.0/8) and continues with the next two checks, but these are skipped because of previous DNS errors. As no checks could identify the mail as being spam, the mail is delivered to the users mailbox. With some creativity this can also be used in SPF records (via spam2.example.com), sender-domains etc. conclusion If you want to save resources by skipping DNS-based checks after another (DNS-based) check failed don t! Think whether this is really the same error you are seeing Additionally this can be used as a sort of DoS against the not said software: according to the logs each of my tries needed between 30 and 36 seconds (!) to complete imagine some hundred simultaneous requests the end You think I did something wrong with that post? Throw the first stone then, I don t care.

There are corners of the Internest where foolish people congregate, and invent stories. These foolish stories are then read as gospel by trusting people, and reposted, until the original made-up source is concealed from view. As an attempt to stem this flow of disinformation, here are some commonly held but incorrect beliefs about the Mono framework, and an explanation of the reality of the situation, as far as I understand it. The next Mono version is co-developed with Microsoft There is a grain of truth behind this one, but it s a gross mischaracterisation. Mono 2.8, when it ships, will bundle, for convenience, a number of Free Software libraries, which are released by Microsoft under a license considered Free Software by the Free Software Foundation, the Ms-PL. These are:

• System.Web.Mvc and System.Web.Mvc2: ASP.NET MVC, a library for writing ASP.NET web pages with a model-view-controller design, similar to Rails for Ruby. This is not news System.Web.Mvc has been bundled in Mono since Mono 2.4.2 (June 25th 2009). System.Web.Mvc2 has been bundled in Mono since Mono 2.6.7 (July 14th 2010).
• System.Numerics: Mono re-uses Microsoft s implementation of BigInteger.cs from the Dynamic Language Runtime (see below). This is indeed new to Mono 2.8, as it is part of .NET 4.0 (Mono 2.8 targets .NET 4.0 compatibility by default).
• System.Data.Services.Client: The OData SDK client library. This is indeed new to Mono 2.8.
• System.ComponentModel.Composition: The Managed Extensibility Framework, a library for writing and using plugins. This is similar in scope to the existing Mono.Addins project. This is indeed new to Mono 2.8, although it was added to Mono Trunk in 2009.
• System.Web.Extensions: Microsoft Ajax, a library for using Ajax inside ASP.NET projects. This is not news MicrosoftAjaxLibrary has been bundled in Mono since Mono 1.2.6 (11th December 2007).
• Microsoft.Scripting.Core and Microsoft.Dynamic: The Dynamic Language Runtime is a framework permitting implementation of dynamic languages (such as Python or Ruby) on top of the core .NET runtime. It is used for IronPython and IronRuby, amongst others. The DLR has very recently changed license from Ms-PL to Apache 2.0, but the version bundled in Mono is still under the older license. This is not news the DLR has been bundled in Mono since Mono 2.6 (14th December 2009).

So, to summarise, there are five Free Software libraries written by Microsoft under the Ms-PL included in Mono 2.8 but only two of those five are new, and none of them were co-developed in any meaningful sense. Mono development is dead There have been reports that Mono development has ended, on the basis that no commits have been made to Novell s Subversion server for a few weeks. However, these reports miss one minor detail Mono has moved to Github.com. There were 35 commits from 9 different people to the main mono.git repository (of dozens of repositories under the main Mono project) in the last 2 days, at time of writing far from dead. Mono lacks features found in Microsoft.NET Mono lacks libraries found in Microsoft.NET, such as the Windows Presentation Framework GUI toolkit. In terms of features, i.e. things implemented at a compiler or runtime level, Mono is typically more advanced. This is helped in no small part by Mono s Free Software development model, allowing experimentation and what if changes to the core runtime which a sluggish corporate behemoth like Microsoft cannot accommodate. To give three real-world examples, Mono allows embedding of its compiler as a service, and provides a REPL shell this is a planned feature for .NET 5.0, but has been available for years in Mono; Mono.Simd provides a number of data structures which will run on any version of Mono or Microsoft.NET, but will use optimized CPU extensions like SSE when run on a sufficiently new version of Mono, on an appropriate architecture as far as I m aware, there is nothing like this available or planned for Microsoft.NET. Mono is able to produce fully compiled, static executables which do not need to JIT anything at runtime this is used for iPhone compilation, for example, where JITters are not permitted. There is no comparable feature in Microsoft.NET. Clearly, Microsoft.NET can only be thought of as more featureful if one defines features in terms of does it have lots of libraries? in terms of functionality, Mono is ahead. Mono can sneak onto your system without your knowledge If you don t have the mono-runtime package installed, you can t run Mono apps. It is possible to install some Mono apps alongside the awful-yet-popular mononono equivs package, since the popular equivs script fails to place Conflicts on the correct packages (F-Spot will be blocked, Tomboy will not). No package in Debian or Ubuntu embeds its own copy of the Mono runtime, and we have no plans to make any changes to packaging which would allow execution of any C# application without mono-runtime installed. If one is using a different OS, then things may be different e.g. The Sims 3 for Mac & PC uses embedded Mono, which you wouldn t know about without looking. Canonical are pursuing a pro-Mono agenda, and are responsible for it being pushed in Debian Mono development has been happening in Debian for longer than Canonical has existed the first upload was made in April 2002. Ubuntu is made primarily from software already available in Debian deemed of sufficient quality, and when F-Spot and Tomboy became parts of the default Ubuntu desktop system in 2006, both pieces of software were already available in Debian and deemed of sufficient quality. Nobody working on Mono in Debian is paid by Canonical actually, that s not entirely true, three packages related to accessibility are officially maintained by someone who was hired by Canonical after doing the initial packaging work when he worked for Novell. But the Mono runtime itself, Canonical have no influence over its direction in Debian. As for a pro-Mono agenda , they ve always taken an extremely pragmatic approach to language choice, never showing any real preference for one language or another when it comes to app selection. They don t exhibit any overt anti-Mono policies, which is not the same thing. The names of people contributing to Mono in Debian are not secret check the pkg-mono team page on Alioth. The System.Windows.Forms namespace is protected by Microsoft patents The truth is, nobody knows for sure if SWF, or any other part of Mono, or any other framework such as Vala or Python, is covered by Microsoft patents. The way the US patent system is contrived, it is actively dangerous to check whether something contains any patents when you write it, as you are liable for triple damages should it later emerge that there WAS a patent, even if your searching missed the fact. You cannot patent an API or namespace only a specific implementation of a software concept, in those countries where software patents are permitted. There has never been any evidence shown that Mono s implementation of SWF, or indeed any part of Mono, infringes any Microsoft-held patents, because if that were the case, then the code would be rewritten to avoid the issue much like the approach taken by Linux kernel developers when a patent becomes apparent. The belief within the Mono community is that the core parts of Mono as defined in ECMA334/335 are safe (they are covered by the Microsoft Community Promise patent grant); any of the Ms-PL libraries mentioned above is definitely safe (Ms-PL includes an explicit patent grant); and the rest of the package is likely safe too (on the basis that it is a named component of the Open Innovation Network s list of protected software and on the basis that there s unlikely to be anything patentable in one of many implementations of basic ideas like database connectors). Nobody knows for sure, because that s how the system works. But, again, nobody knows for sure that Microsoft patents don t apply to other frameworks such as Python there is simply a belief and an assumption that they do not. MonoDevelop contributors removed GPL code from MonoDevelop, in an attack on the GPL This is somewhat disingenuous, given MonoDevelop is LGPL. The MonoDevelop team excised the remaining GPL code (and there wasn t much of it) in order to grant greater Freedom to developers. Previously, the entire MonoDevelop IDE was a GPL combination, meaning any add-ins for the IDE also needed to be GPL, regardless of developer choice. Now, any developer can write an add-in for MonoDevelop, using the license of their choice, whether another Free license like the Mozilla Public License, or a proprietary closed-source add-in. They are still welcome to produce GPL add-ins, if they want to, as well. Mono won t run random Microsoft.NET apps anyway, so isn t really cross-platform Actually, this one is often true. When developers write apps for Windows primarily, they rarely take the time to think is this the correct way to do it? and will often plough on with an assumption about the Windows way of doing things. It might be simple things like filesystem assumptions (assuming a case-insensitive filesystem, or assuming a backslash is used to separate directories, not a forward slash). It might be more involved, such as using P/Invokes into Windows-specific C libraries, when a more cross-platform alternative is possible. So, often, random applications for Microsoft.NET won t run on Mono. The reverse is also true F-Spot or GNOME Do are fairly heavily tied to Linux (or to UNIX-like OSes with X11, at any rate), through the libraries they invoke being fairly platform-specific. You can write platform-specific Java, with one quick piece of JNI, too. It should be noted, however, that Mono makes the chance of .NET applications being ported to Linux (and/or Mac) much more likely, since even in the worst case scenario, a company only needs to fix a portion of their source to make it cross-platform. The Mono team have a tool called MoMA, which will scan an application and its libraries, and give you detailed reports on the app s portability. This info is used at both ends by app vendors who want to become more portable, and by the Mono team who want to fill in the most frequently encountered blanks. And, it should be stressed, writing cross-platform apps is entirely possible if one desires it e.g. the IRC client Smuxi is pure cross-platform C#, and the executables compiled on Mono on Linux will run fine on Microsoft.NET on Windows. Portability in this direction is important too consider how many people have been introduced to Free Software thanks to availability of Free apps on Windows like OpenOffice.org, Firefox, Pidgin or GIMP. You can download Tomboy for Windows, and work is ongoing on fixing Banshee portability issues (which are mostly caused by gStreamer). Mono on Android is a terrible idea which will be super slow There are two efforts to enable developers to write Android applications with Mono a paid proprietary product from Novell called MonoDroid, and an untitled porting effort by big-name Android hacker Koushik Dutta. I have no insight into MonoDroid since it hasn t been released yet, but Koush did some benchmarks of his work which exhibited some remarkable figures compared to Dalvik (and even compared to Sun Java for ARM). Those numbers haven t been updated to reflect the Froyo Dalvik JITter, but Mono on Android is still very exciting from a performance perspective. Mono isn t really Free Software The source code is all available under Free Software licenses. So, um, yes it is. We don t need Mono because we have $LANG By the same logic, we don t need $LANG because we have Mono. By all means, use the language of your choice other developers will use the language of their choice too. If you want to use Vala or Python or Java, then by all means, go ahead. It doesn t mean there s no room for more languages, better suited to other usage patterns. Haskell is great for some types of development, so is Fortran, and so is C#. You might not need Mono because of $LANG, but there are others in the world with different needs. Mono apps are all slow, and crash your computer, and stuff No userland app can crash your Linux system, unless there s a bug in the kernel, or you have some severe problems with your hardware. If you ve ever observed a crash as a result of running a Mono app, then it s really coincidence that Mono is tickling whichever part of your system is busted. As for slow startup time may well be slower than for apps written in C or Vala. There s a delay due to the JITter needing to compile all the libraries used by the application (we may AOT the most common libraries in a future Mono package version, at upstream s recommendation). Once an app is running, it should be fast compared to a Python app, and memory-light compared to a Java app. The new garbage collector in Mono 2.8 should also offer significant improvements to performance, especially under heavy workloads. Ubuntu s default GTK+ themes require Mono This is my favourite recent nonsense to emerge from the Internest. There are reports mostly restricted to IRC and blog comments, that (paraphrasing here) removing Mono removes the Ubuntu themes . Here s the reality: in Ubuntu 10.04, a new visual style was implemented throughout the distro. As part of this, small icons (e.g. notification area icons) were set to be black-and-white by default, and colourised when attention is needed (e.g. the power-off icon turns red when a reboot is needed, the messaging indicator turns green when there s a new message). All of these new monochrome icons are in a package named ubuntu-mono . Removing the ubuntu-mono icon package will also remove the new Ubuntu GTK+ themes, in the light-themes package. So there s your explanation: the themes have a dependence on some monochrome icons, not on the Mono framework.

Like many people I use Apache's mod_proxy to proxy from *:80 to a bunch of servers running upon 127.0.0.1:XX. (I've mentioned this too often; but in short I have a bunch of sites all running with thttpd under their own UID). Why do I use apache soley as a reverse proxy, instead of pound, varnish, nginx, or lighttpd? After all it is pretty heavy-weight. Well the answer to that is that I have a bunch of mod_rewrite rules. So I'm wondering, could I drop apache if I were to hack together a simple network proxy that would listen upon port 80, reading requests, and directing them to local servers? The answer to that is plainly "yes". There are many reverse-proxies around and writing them isn't hard. So what would be the point? Imagine a reverse-proxy that understood mod_rewrite rules. That would rock. In short we'd have to define three things:

• Matching vhost name.
• Destination to proxy to.
• (Optionally) the mod_rewrite rules

Given something like this:

LISTEN 1.2.3.4:80
host example.net or host www.example.net
 
   #redirect traffic here
   proxy_to 127.0.0.1 1011
   RewriteRule /about /cgi-bin/index.cgi
 

When the proxy received an incoming request to http://example.net/about it would actually send the request /cgi-bin/index.cgi to the host 127.0.0.1:1011. That seems neither too complex nor too impossible. The hard part would be emulating mod_rewrite 100%. Especially chained requests. I would be willing to write the trivial version, but I suspect the full emulation would be a job of diminishing returns. Am I right? ObSubject: You crossed the line first, sir. - "The Dark Knight"