Euro-IX is looking to sponsor Quagga development. This was announced by Nick Hilliard in a post to the quagga-dev list. This is really great to see and I commend Euro-IX for providing these resources for Quagga.
Microblogging / Social Networking updates
Micro-blogging, like Twitter is the latest rage. Not understanding why I, of course, have decided to try it out. My Twitter account is pauljakma, and my Identi.ca account is paulj.
Identi.ca is quite handy as it has the ability to connect to Twitter and Facebook, and update your status there as/when you update your status on it. I am also using gwibber, a Linux/GNOME micro-blogging client which can connect to several social-network and micro-blogging sites, including all the above. The resulting flow of messages is best described here. I have also installed mobidentica, a light-weight Laconica/Identica client for Symbian S60, onto my Nokia E51, for on the go micro-blogging but I haven’t really used it in anger yet.
So basically, I can update my status on Twitter, Identi.ca and Facebook all in one place. E.g. from Gwibber, if I’m using my desktop; or via Identi.ca if I have access to a browser; or mobidentica via my phone. Identi.ca can also synchronise with services that use the Jabber IM protocol, like Google Talk and Nokia’s Ovi chat client.
The one downside is that there may be a bit of an impedance mismatch in audience between different micro-blogging/social-network sites. E.g. my Twitters/’dents tend to be more techy, which could seem strange to various Facebook family and friends who are not techies.. It’d be nice if Identi.ca had a fine-grained, in-line way to control which ‘dents were sent to Facebook.
Fewest radix-10 digits needed to hold any given radix-2 number
Was trying to work out a function to map the size, in base-2 bits of a number, to the minimum number of base-10 digits needed to represent the number (and to useful: if the function has an error the error must be upward). I couldn’t work out anything, so I wrote out the numbers to see if there was any obvious pattern. And hey presto:
| bits | Min base-10 | |||
|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 1 |
| 4 | 5 | 6 | 2 | |
| 7 | 8 | 9 | 3 | |
| 10 | 11 | 12 | 13 | 4 |
| 14 | 15 | 16 | 5 | |
| 17 | 18 | 19 | 6 | |
| 20 | 21 | 22 | 23 | 7 |
| 24 | 25 | 26 | 8 | |
| 27 | 28 | 29 | 9 | |
| 30 | 31 | 32 | 33 | 10 |
| 34 | 35 | 36 | 11 | |
| 37 | 38 | 39 | 12 | |
| 40 | 41 | 42 | 43 | 13 |
| 44 | 45 | 46 | 14 | |
| 47 | 48 | 49 | 15 | |
| 50 | 51 | 52 | 53 | 16 |
| etc.. | ||||
A sufficient function must then be, using C-ish notation, and assuming ‘/’ is an integer divide:
f(x) -> (x%10 <= 3 ? (3x / 10 + 1)
: (x % 10 <= 6 ? (3x / 10 + 2)
: (3x / 10 + 3))
Update: f(x) -> (x % 10 <= 6 ? (3x / 10 + 2 : (3x / 10 + 3))
What I’m wondering though is:
- Was there a better way to work out the function?
- Is there a neater way of expressing it?
Update: As cjb points out:
2 = 10^n
=> n = log(2)/log(10)
=> 2^p = (10^n)^p
=> 2^p = 10^(np)
ergo, for any given p, ceiling(np) digits are required
As I’m a bit dense, cjb had to re-explain it to me in terms of information content. To paraphrase (hopefully not too badly):
1 digit of base-10 has log2(10) bits of information, and similarly 1 digit of base-2 has log10(2) (ie 1/log2(10)) decimal units (aka ‘hartley‘) of information. Therefore, n binary bits have nlog10(2) hartley’s of information. Round this up to get the minimum required decimal digits.
cjb also pointed out a transcription error in the function (left out the multiply by 3). He has some other interesting points I’m still trying to get my head around :).
Update2: CJB points out there’s a problem with my table, and hence with my function. The below again paraphrases his explanation. My table assumes that for every additional 10 bits, that this corresponds perfectly with an additional 3 decimal digits (hence the recurring pattern). I.e. that the ratio is 10:3. However, this isn’t the case – as we can see from above, the ratio is actually:
1 : log10(2) = 3.322
This is obviously quite close to, but not the same as the 10:3 ratio in the table . Therefore the table diverges very slowly from the actual answer. To find where it diverges sufficiently to throw off the table:
the divergence ratio is 1024:1000, for every 3 rows.
so the divergence reaches 1 at: 3/log(1.024) ~= 291.2
so the columns of the table become out of sync around 291.
And lo and behold:
table:
292*3/10+1 = 88
293*3/10+1 = 88
by nlog2(p):
292*l(2)/l(10) = 87.90
293*l(2)/l(10) = 88.20 (oops, too big for 88)
Discrepencies actually occur between the 2 methods prior to this, at 103, 113, 123, … I don’t have an explanation for those as yet. Just removing the <= 3 band, and having those values use the <=6/+2 band allows the integer-only method to work up to about 1073 bits.
Cjb has a better method, more precise and robust and integer only:
f(x) = 30103x/100000 + 1;
which is good up to about 13300 bits!
How to make it easy for a maintainer to apply your patch
- If you don’t know git, take a day or two to learn (it’s not that hard, and the gitk and git-gui GUI tools can help a lot)
- Read through the existing commit messages to get a feel for the common style – and try use this style in your own commit messages:
- A one-line summary as the 1st line of the commit message. You may wish to start it with ‘applicability:’, e.g. ‘bgpd:’, ‘netlink:’, ‘freebsd:’, etc. This is used for release announcements.
- The body of the commit message, containing a high-level description of the goal of the changes, including the problem being addressed and the reasoning for the commit, on a change by change basis (e.g. per file, even per-function, if that’s appropriate). For a large commit, an introductory overview may be needed.The goal is two-fold: To force the submitter to perform a self-review of the commit (and so catch problems); and to give the reader the required context to review the commit.
- An honest indication of the confidence you have in the patch, including what, if any testing has been done.
- If the patch contains work done by others, e.g. because it is a rework of some other patch, indicate this. Though, ideally, the original patch should be a separate commit, attributed correctly with the –author argument to git-commit.
- Read the HACKING document (parts are out of date though)
- Prepare a branch, based on the Quagga.net master, that contains your changes and nothing else (merges from master are ok; if you need to merge it together with other things for your own purposes, then use another branch – they’re cheap).
- If you like to rebase published branches, please name-space such branches with a ‘volatile/’ prefix.
- Order the commits so the that the safest, least-contraversial commits are earlier in the branch than patches that are less likely to be mergeable. This allows maintainers to, perhaps, still be able to pull part of your branch if some patches are deemed problematic.
- If you have a large and/or less-obviously-safe patch, try to split the patch up into smaller ones. E.g. there may be infrastructural improvements that can be factored out and go in first.
It’s extremely rare that contributors do all of the above. Commit messages in particular are often free-form. Sometimes they describe the problem, but not why the change fixes it. Sometimes the change is described, but without reference to the problem. Sometimes the message is akin to a C-to-english transliteration.
It might seem like a pain to force submitters to spend 5 to 10 minutes to go through their patch and construct a structured, detailed, but high-level description of their patch and their intent. However not doing so forces the reviewer to spend even more time to mentally construct the same. If you have many contributors feeding patches to a small number of maintainers, then it just doesn’t scale unless contributors make an effort to make their patches as reviewable and easy-to-integrate as possible.
In short, try to make life easy for your maintainer. There are several small, maybe even apparently trivial, things you can do quite easily which help reduce their load, and help smooth your patches’ path.
Updates: Git strips out []’s, so change section recommending patch subjects encode information in them.
Stupid, false, aviation memes: #273
Given recent, unfortunate news, a lot of uninformed people are repeating the old, false “Airbus crashed cause pilot was overriden by computer!” meme about AF296, when an Air France Airbus, making a low-level fly-past of an airfield, crashed into trees at the end of the field.
The actual facts of the matter, as determined by the official investigation reports, unless you choose to believe the conspiracy theories, indicate the crash was due to a number of human faults on the day.
- The flight-crew were not properly briefed – the charts provided to them of the airfield (and to which AF did not usually fly) did not show the high-trees at the end of the field.
- The captain disregarded audible warnings from the highly accurate radio-altimeter and instead relied on his less accurate and/or miscalibrated barometric altimeter, which led him to make the fly-past at around 30m AGL instead of the 100m AGL he had been instructed to make it at (which would have prevented the crash).
- The pilot applied power too late to climb above the trees. There are some suggestions the engines failed to react (from which the false meme about the computer overriding the pilot seem to have sprung), however high-bypass, fan jet engines are known to be slow to spool-up at the best of times, even more so at low-altitude and low-speed. It’s also possible one engine may suffered a performance problem right at that time, due to an understood feature of turbo-fan jets (compressor stalls) – one which Airbus re-iterated in a technical memorandum not long before the crash, which the captain likely would have read.
In short, there were a series of errors. Even being kind to the captain, he failed to fly at the approved altitude and he failed to leave sufficient margin to allow for the physical, performance limitations of his engines. It was, in the greater part, caused by pilot error.
More comments (some useful) are in this slashdot story sub-thread.
Working on Quagga over the summer, thanks to Vyatta
I will be working on Quagga full-time, hopefully for the whole summer, thanks to sponsorhip from Vyatta.
The plan is, amongst other things, to get through the outstanding queue of patches and get at least 2 releases out, with a good, well-tested and stable release toward the latter part of the summer.
Hello world!
This is my new, personal blog site – taking over from
my old, Sun blog.
Welcome 🙂
Paul Jakma's Blog 
You must be logged in to post a comment.