Yesterday, my co-worker notified my about a promotion of 3DSupply and I recognized, that they have new design and you have also the choise to select from various models and colors for your shirts. I like the new site much more than the old.
For just speading they word, they offer to give a shirt (or any other item < 20 Eur) for free. So it seems to be a good idea to equip my dear wife, which is a teacher of catholic religion, with a new Jesus shirt.
Update: Today I got a reply from 3DSupply, stating that they deny the shirt request, cause I don’t have 10 posts in the last 6 month. As this is unfortunately true, due my always limited time, I can’t find this hard requirement in their terms. Looks like my blog doesn’t match their minimal requirements and I’m advised to equip my girls somewhere else with geekware. :o)
While I normaly don’t care much about Ubuntu, I’m subscribed to lauchpad.net for the packages I’m involved within Debian.
Sometimes apears informative stuff there, which reminds me about my todos or just pointing me to real problems. Most of the time, I’m just ignoring the reports, as the are useless or just unrelated to me packages in Debian.
But in some cases the reports are just making my day.
In the last days, I replaced my Nokia E90 with a Nokia N97 mini. As I’m using my mobile from time to time to hook up to the internet when traveling, I thought I just need to replace the MAC in my /etc/bluetooth/rfcomm.conf and that’s it. As always … Murphy striked back. After debugging for hours I realized the DUN channel seems depending on the model.
You can discover your DUN channel something like:
# hcitool scan
Scanning …
3C:F7:2A:1A:4D:2A Cycophone
# sdptool browse 3C:F7:2A:1A:4D:2A | \
grep -9 “Service Name: Dial-Up Networking” | \
tail -10 | grep Channel
Channel: 22
So your /etc/bluetooth/rfcomm.conf should now look like:
…
rfcomm0 {
bind yes;
device 3C:F7:2A:1A:4D:2A;
channel 22;
comment “Cycophone”;
}
…
Last night here at BSP I released nagios-plugins (1.4.14-1), which has a couple of fixes and enhancements. For more information, see the changelog.
The main change may, that with this version, the package should be installable on non-linux archs, where iputils-ping is not available. The downside of using inetutils-ping is, that its behavior is different from iputils-ping. As result of this, check_ping will timeout much often, even if there isn’t any problem and you will have false positives. As suggested long ago, at least on this archs, you should consider to replace the use of check_ping with check_icmp.