Daniel Lange's blog

Bryan Østergaard (aka kloeri) announced Exherbo today. He assembled a team of (ex-)Gentoo developers including Ciaran McCreesh (ciaranm), Richard Brown (rbrown), Fernando J. Pereda (ferdy) and Alexander Færøy (eroyf) to build a new source based Linux distribution.

They would like to overcome some of the short-commings of Gentoo both from a technical as well as from a community perspective. Obviously this is easily said and hard to really achieve, so time will tell how successful that team can be. Renaming USE-Flags to OPTIONS and merging the platform KEYWORDS (like x86, ~x86) into the Options-logic is no big deal, but getting the thousands of ebuilds^Hpackages better supported and maintained than Gentoo will be the real deal{maker|breaker}.

Paludis, ciaranm's package manager, supports Gentoo ebuilds and can import them into Exherbo, so there is a potential migration path sketched out.*

They also add another init-system re-write ("Genesis") to the pool. An already quite crowded pool with rather shallow water, I may add.

Exherbo has nothing that is end-user-safe at the time of the announcement, so it's safe to assume kloeri's team wants to attract further development capacity .

Browse around the website or join folks in #exherbo if you're interested.

I asked in #exherbo what "exherbo" means ... latin for "uproot" was the answer. How fitting.

Updates

*19.04.08: Two friendly folks wrote in to clarify that Paludis currently can only import Ebuild-builds into Exherbo via importare, i.e. take a Gentoo build result and package it for importing into the Exherbo system through Paludis.
23.05.08: Ciaranm wrote a blog entry how to get build results into Exherbo/Paludis via importare.

Xing has just updated it's image-thumbnails naming "algorithm" once again:

You'll now find thumbnails named /2f1127fe2.3144098_s2,2.jpg, so including another component like <comma><digit> added to the name. Thus the Greasemonkey script linked from my article Greasemonkey to enlarge Xing pictures needs to have it's main regex amended:

Change \_s(1|2|3)?\. to read \_s(1|2|3)?(,\d)?\. in three places in the script.

Or download an updated version here. I hope "louis" will update the version hosted at userscripts.org, too.

Updates

02.05.2008 As Xing adds multi-digit numbers to the thumbnails now (like /7553bd445.4550412_s2,10.jpg), you need to replace \d with \d+ in the above regex. The linked Greasemonkey script is updated.

16.11.2011 And again the URLs changed. This time appending a pattern like ,4.57x75.jpg. The linked script again was updated. If Scriptish and the auto-updating in Greasemonkey mature, I'll add auto-updating to the script file via the @updateURL parameter.

13.05.2012 The Xing layout is still changing as they Ajaxify the site more and more. Currently the Xing XE is probably the best working enhancement to see Xing pictures in a recognisable size.

I use Xing to manage some of my business contacts and even some friends have profiles there as well.

The default size of contact's pictures displayed on one's Xing homepage is 18x24px. On a higher dpi screens, you can thus barely recognize the person shown. As there are multiple sizes of all images available, it's pretty easy to just take (for example) http://www.xing.com/img/users/d/f/1/f34814409.5648827_s1.jpg, remove the _s1 and see a 140x185px version of the picture.

Greasemonkey, a Firefox extension to run user specified scripts on selected pages that you visit, can automate this with a nice script from user louis to download here. Or my updated version here.*

So, everytime I now hover my mouse over a tiny Xing thumbnail, it will show the "full resolution" version of the image. Simple, efficient.

Update

* Xing changed it's image naming scheme a bit, so one needs an updated Greasemonkey script for all images to work again. Link inserted into the article text ("Or my updated version here.")

Eric Möller has published his report on the Wikimedia 2007/2008 fundraiser. I found it because he hotlinked one of the images that I created for my detailed analysis. His report lists some interesting new information:

• Wikimedia got $50,000 in Google stock from another - yet again - anonymous donor.
• The Wikimedia chapters (local organisation units e.g. in Germany or France) have collected nearly $250,000 in their fundraisers (mostly in Germany). The Germans buy stuff of their own from the money. Only the Swiss donated 25% of their raised budget back to Wikimedia foundation. Eric explains: "The lack of a clear understanding between chapters and the Foundation about the role and responsibilities of the different entities in the fundraising process is an additional impediment. For example: Should chapters share fundraising revenue with the Foundation, and if so, how? [..] The German chapter has an informal agreement with the Foundation to invest half of its fundraising revenue in ways directly benefiting WMF projects."
• Eric says it was not intended to raise the full $4.6m. Somehow people just mis-interpreted the fundraiser that way: "The publication of the planned spending was misunderstood by some to indicate that the fundraiser's goal was to raise 4.6 million dollars. [...] Inquiries related to the actual financial target of the fundraiser were less common, probably in large part due to the publication of the Foundation's planned spending."

The report is extremly low on self-criticism. There is no insight visable that not giving a financial target was a major bummer or that the general intransparency, unprofessional communication and amateurish reporting on financial issues was keeping many people from donating. Nothing about missing the 100,000 donors target, either. There is not a word on the webcomics deletion issues and the subsequent call by the webcomics community to boycot the fundraiser or the scandal around hiring a convicted felon as COO because of unprofessional HR work. Not a word on the ridiculous "dinner with Jimmy Wales" for people donating $25,000. Nobody even donated $10,001.

"Also, given that most of the viewers of the planned spending distribution had no financial background, the level of explanations given was probably not sufficient." Come on, Eric, the people with financial background are not even considering the published material as "planning".

And next time, please link a blog entry and not some graphics. Criticism is healthy. Let people develop an opinion of their own. Try putting a "public criticism" section into your report. It will definitely add to the report's credibility.

Update

03.02.08: Eric has ammended information from the Italian chapter. They raised around $3,000 and forwarded it all to Wikimedia foundation.

The official Wikimedia fundraiser had been extended into January, 3rd 2008, has been kept up on the 4th and is kind of still running. The site notice has been trimmed down to a thank you message but still requests further donations, which are also continuously added to the official daily funds list and running totals as of the press time of this article.

I've presented two interim analysis

• Wikimedia Fundraiser analysis I on 03.11.07, some two weeks into the fundraiser
• Wikimedia Fundraiser analysis II on 23.11.07, summing up expectations and results for the initially intended duration of the fundraiser (22.11.07)

Today, let's wrap up the fundraiser until the second official close date 03.01.08:

From 22.10.07 until 03.01.08 43,837 people have contributed a total of $1,467,446 (US) according to Wikimedia's own stats (see the previous two articles mentioned above for a discussion of their reporting scheme).

SSH with chroot patch has been working fine for a number of years. Since PAM v0.99 things have broken though, if users are chrooted with the "/home/username/./" syntax as their homedir.

SSH sessions will just terminate immediately after successful logon. Doh.

Two solutions exist:

1. Put UsePAM no into /etc/ssh/sshd_config and use the chroot patch and /./ in users homedirs
2. Keep UsePAM yes. Emerge sys-auth/pam_chroot and add session required pam_chroot.so to /etc/pamd.d/sshd setup /etc/security/chroot.conf or add a chroot_dir=/home/username/ to the pam_chroot.so line.
   This will currently not work for amd64 though as the Gentoo bug regarding pam_chroot has not cought any attention from the arch testers. Since July...

Bugging the arch testers in #Gentoo-amd64 didn't help either:

The Wikimedia Foundation has changed their donation web pages again. Now they cut off the "Recent contributions" at 400 pages of (max.) 25 donors each. Thus the commands I gave in the Wikimedia Fundraiser analysis article can't be repeated to give the full picture anymore. You can now only get a view of the last 9-10 days.

The implementation has obviously been done quite hastily. If you select the "Filter" to show only one page of results, you'll still get the (now hard-coded) 0 .. 400 pages selector at the bottom.

I've been pointed at two other resources on the recent fund raiser for information:

• There is an IRC Channel that lists donations (irc://irc.freenode.net/#wikimedia-donations). Running it a few minutes, it showed far fewer donations coming in than the better known web page though.
• There are a few threads in the Wikipedia Review Forum that deal with the fund raiser. The discussions there are very Statler and Waldorf style but these folks also did the math.

Updates

09.11.07: Casey Abell has added http://donate.wikimedia.org/en/node/22 to the comments which lists a daily report of the funds collected. Thanks Casey! The numbers match very well with my analysis. Wikimedia currently reports $27,97 average donation. I measured $27,85 six days ago. That seems stable. Interim conclusion:There are still major individual donations required to get anywhere above $2m.

10.11.07: Casey generates a nice graph of the daily funds collected here.

The Wikimedia Foundation, the organisation behind Wikipedia, is running their annual fund raiser since October 22nd. There have been numerous complaints that the Wikimedia Foundation did not name a target sum to be achieved or is in other way acting intransparent. There may be good reasons for that:

• The last fund raiser was "tough" to get through already and raised about one million dollars with $20 average contribution as to what Bruno Giussani reported from Lift '07.
• The foundation grew from $56,666 turn-over in it's fiscal year 2003/2004 to $283,487 (2004/2005) and $1,066,785 (2005/2006). The 2006/2007 figures are still not reported, but it's safe to estimate that the 4x increase of the previous year has slowed down a bit.(see Updates section below) See http://wikimediafoundation.org/wiki/Finance_report for the scarce details.
• The budget planning for fiscal year 2007/2008 totals $4.611m. The break-down is very rough and little effort is spent to explain the figures to the general public.
• The suggested donations have been set high at $200 to $40 with marketdroid speak to sell that:
  "If you and 99 other people donate .. $200 – We can ...".
• It's not very likely a target in the range of the planned budget can be achieved from Joe, Dick and Harry's contributions. Wikimedia may need Larry, Sergey or Mark here. (I'll leave that without links for you to think about )

So - to make the best of this - and continue being unnecessarily intransparent, Wikimedia (cough Jimmy Wales, cough) has decided to only list the number of donors as the "progress report".

Their "meter" currently looks like this:

You can easily analyse the scale to find that Wikimedia hopes 100.000 people will contribute.

I just learned yesterday again, what I knew a few years ago, but since had forgotten:

You cannot put multiple SSL-enabled virtual Apache hosts onto the same IP and port.

Apache cannot identify which VirtualHost to serve a request from because the payload is encrypted in its entirety. So a

Host: servertwo.tld

header cannot be parsed until the encryption has been removed. Which requires the key, which is listed in the VHost section that could not be identified in the first place... So a name-based VirtualHost-configuration like this won't work:

It will just serve any request out of the first VirtualHost (serverone.tld) regardless of the hostname in the request headers.

There is some light at the end of this tunnel though: RFC4366 describes an optional field to the TLS (Transport Layer Security) client request called "Server Name Indication" (SNI). With this the client just includes a list of ServerNames (usually one) that it's trying to contact. Apache can easily match the supplied name from the client against a ServerName (or ServerAlias) directive from it's configuration files.

SNI will be supported with OpenSSL v0.9.9 in mod_ssl. Sometime in the future. There is a backport to v0.9.8 available from Steven Henson linked here. Or you can use mod_gnutls as described by George Notaras in a recent blog entry.

In either cases the above configuration snippet will "just work" once SNI is understood by Apache.

Currently Internet Explorer 7 (on Vista only, wanna upgrade ), Mozilla Firefox 2+, Opera 7.6+, KDE Konqueror 3.5+ support sending the SNI. You can test your browser at Kaspar Brand's SNI testpage. He also has a patch available to make Apache 2.2 mod_ssl SNI capable when compiled against a CVS-version of OpenSSL.

I'm rather sure that spreading SNI capable hosts will also provide new hacking opportunities: Let's assume a system serves both Intranet and Internet traffic. A client contacts the Internet IP with SSL but specifies the Intranet Hostname in it's TLS SNI entry. Guess what will happen? Yup.

Update

02.09.2009: Gee, after two years people still read this blog entry. So I'll point you to a few updates. 2009 is not 2007 SNI has made some slow progress since the original article. But major steps forward only came this summer: Apache has official support for SNI since 2.2.12 (tracking bug). Gentoo has been early to support SNI and Tobias Scheerbaum has written a blog entry on Apache, SSL und SNI in Gentoo (in German) summarizing how it works out of the box. Support for SNI has also been added to Debian (tracking bug) but for now the default config files don't reflect SNI capability yet. Ubuntu will see SNI in Karmic Koala, the release scheduled for next month i.e. "9.10" (tracking bug). Fedora has a SNI enabled Apache from httpd-2.2.13-1.fc11 onwards (tracking bug). Tobias also states that SP3 for Windows XP enables IE6 to send the SNI (SP2 is not sufficient).