Go and have a look at the Antix Games Store.
By the way, the proper URL for the Antix Games Store is http://www.antixgames.com/, and not that thing ending in "/en/". Yes, when you go there, you end up on the URL ending in "/en/", but that is the language-specific top-level page. The proper and correct URL to share and link is http://www.antixgames.com/.
Netgear DGN2200 review: Don't buy. Zero stars out of Five.
Do you do Perl? If so, you might like to try perldoc.co.uk. It's like perldoc.perl.org, only it's not perldoc.perl.org, so when perldoc.perl.org goes down, perldoc.co.uk stays up. Plus it's UK based, so for people in the UK and the rest of Europe, it should be quicker.
I bought a Netgear DGN2200 (from Amazon) to replace the DG834Gv4 which appeared to have failed (all lights coming on).
As I'm talking about two devices here with gobbledegook codenames, I'll highlight them differently in different colours. So the new (bad) one is the DGN2200, and the old (good) one is the DG834Gv4.
(As it turned out later, the DG834Gv4 hadn't failed; only the power supply had expired. By pinching the power supply from my previous-previous router (DG834Gv2), which was also 12V 1A with the same pinout, I was able to get the DG834Gv4 going again.)
Back to the DGN2200, it is a case of: Nice hardware, shame about the firmware. The DGN2200, as offered in its current form, is a load of rubbish. In a couple of years, assuming the firmware gets fixed, it could be a good little router. But today, don't touch it with a bargepole
The DGN2200 seems to incorporate a perfectly decent DSL modem. On my somewhat lengthy telephone line, I get a DSL synch rate which is in the same ball park as the best I have seen.
Also the DGN2200 seems to incorporate perfectly decent wireless hardware. As far as I could tell, all my kit seemed to connect up to it easily and maintained a reliable connection.
The problem, and it's a biggy, is the network software:
If I try to access an HTTPS website on a non-standard TCP port number, then I find that it takes 5 or 6 attempts to connect. Now, this might look like simple packet loss, or perhaps the MTU is too large. Well, sorry, no, for several reasons:
If I do swap test with the old DG834Gv4 router, the DGN2200 fails on this point whereas the DG834Gv4 doesn't. The DG834Gv4 connects first time, every time.
I can run a simultaneous ping which shows 0 out of 100 packet loss. Also I can run a simultaneous SSH session which is consistently snappy and responsive. So why do ping and other services work reliably but HTTPS (on a non-standard port number) doesn't?
I can take the MTU down to 1400 or 1350 and there is no difference. In any case, why does the DG834Gv4 work fine when the DGN2200 fails miserably?
I tried monitoring the HTTPS packets on the server side using tcpdump. When the problem is manifesting, the server does not see any initial packet arriving. So the server has no cause to respond. The packet is simply not arriving, and everything points to the packet being lost by the DGN2200.
More problems: If I try to set up an OpenVPN connection to a server listening on UDP port 1195, it takes 5 or 6 attempts before it connects. Packet loss or MTU? Nope, for the same reasons as the first problem. Again, the DG834Gv4 connects first time, every time.
I tried raising support requests through Netgear, but we were moving at a snail's pace, and besides I now have the old router working again.
So I have raised an RMA through Amazon and the DGN2200 is going back. Update 2010-11-04: Amazon have now issued a full refund for the unit.
In addition, I have advised Netgear that I would be more than happy to consider assisting them on a consultative basis.
More idiotic behaviour from my utterly useless bank.
A transaction appeared on my credit card statement with the description:
CRALECELECT 44845508105
CRALECELECT? What's that then? A single word Cralecelect? Crale Celect? Google for it? Zero hits.
What about the number 44845508105? Looks a bit like a phone number +44 845 508105. Unfortunately not enough digits.
Why can't my bank pass on some USEFUL information which would help me to identify the merchant?
After some head scratching, I have worked out that it is Cralec Electrical Distributors. I placed an order with Elite Electric, which seems to actually resolve down to Cralec Electrical. Their phone number is 0845 508 1055.
I had placed the order so long ago that I'd actually forgotten about it. Unfortunately they seem to have decided that despite having taken my money, they don't need to actually fulfil my order. I phoned them up today to ask for an ETA. They took my number and said they'd call back. Needless to say they haven't. Ah well.
The bounty now stands at:
EUR 26.77 or GBP 22.12 or USD 34.06
So, Thunderbird 3.1.x adds two spaces to the beginning of every message. Personally, I'm incandescent about this. A lot of other people seem to not care a jot.
This seems to be one of those issues with a wide range of opinions.
There is a bug raised on this issue, Bug 564737. But that bug has been around since May, and, astonishingly, staggeringly, we are now seeing point releases which do not include a fix!
Anyway, I want to get it fixed. To that end I am offering a time-limited bounty.
I will offer a bounty of GBP £5.00 (about USD $7.70), payable by PayPal, to whoever can convince me that they were the key person responsible for getting a working version available for me to download, before 2010-09-23T17:30:00+0100 (that's 14 days from the time of writing).
This should not be a special build but a general release in the normal stable release stream available for Windows 32-bit, under either English-US or English-GB.
And no "funny business" like saying "Thunderbird 3.0.6; payout please". This about getting the bug fixed properly, not playing tricks.
I reserve the right to extend the deadline at my sole discretion.
I know this is not much money, but if other people feel the same way and also offer a bounty then it could make an interesting chunk of cash to get someone motivated.
How do you know I'm going to pay out? I guess you'll just have to trust me. But I promise that this is a bona fide offer, cross my heart, hope to die, etc.
If anyone else wants to join in, please drop me a confidential e-mail with your name, (optional) pseudonym, e-mail address, and amount pledged, to
tb-564747-bounty AT blunn DOT org
(Oops, this e-mail address was not working. I have now fixed it and tested it and it is now working.)
Pledges must be made in either Euro (EUR), United Kingdom Pounds (GBP), or United States Dollars (USD).
I promise to use your details only for the purpose of this bounty. I expect to publish your pledge by way of your name or pseudonym and the amount pledged.
Your pledge will, by default, be on the terms described above, however if you wish to specify your own deadline, you may do that. If you do not, then I will treat your pledge as matching mine.
Your pledge will not be legally binding but will work on the honour system. I may publish a list of those people who do not honour their pledges without providing a good explanation.
I will keep your e-mail address a secret. If you provide a pseudonym, I will also keep your real name a secret. All secrets will be kept unless forced to be revealed by law enforcement agencies or a court order. I will not send out any mass-e-mailing which exposes your e-mail address to others; if I need to send out a mass-e-mailing, it will either be via a configured mailing list, or a bulk BCC; in all cases your e-mail address (and name if pseudonym provided) will be hidden.
If the fix comes through in time, and someone claims the bounty, and their claim is verified, then I can let people know where to send the money.
If more than one person has a plausible claim for the bounty, I will determine what I deem to be a fair split of the bounty and advise accordingly.
I will expect to provide the information for people to send money directly if possible, but if anyone wishes for me to forward funds on their behalf (for example they wish to remain anonymous), I will be prepared to do this, and provide (e-mail) advisories to relevant parties so that they may verify that funds have been correctly transferred. If funds cannot be transferred to the beneficiaries, I will make best efforts to return them to senders. Any fees for sending money, transfers etc., will be taken out of the amounts being transferred (i.e. I'm not in business of handing out my own money willy-nilly).
If you wish to be a beneficiary of the bounty, you must agree to have your real name and the amount paid to you published.
| Name | Amount | Deadline |
|---|---|---|
| William Blunn | GBP 5.00 | (follow scheme) |
| Nikos Bilalis | EUR 5.00 | (follow scheme) |
| Joseph Morris | USD 20.00 | (follow scheme) |
| Total | EUR 5.00 + GBP 5.00 + USD 20.00 |
Do you do Perl? If so, you might like to try perldoc.co.uk. It's like perldoc.perl.org, only it's not perldoc.perl.org, so when perldoc.perl.org goes down, perldoc.co.uk stays up. Plus it's UK based, so for people in the UK and the rest of Europe, it should be quicker.
Had a problem where I had a VM running Ubuntu 10.04 Lucid but we did not have a suitable locale set to make it "work in UTF-8".
What is normally required is for the environment variable LANG to be set to something sane like en_GB.UTF-8.
On the system in question, which was derived from a bare-bones VM Ubuntu, LANG was empty. Pasting a smiley face ☺ into a PuTTY window just made it go bing. Typing a pound sign £ didn't work.
Now back in the good old days we would do something like
But on my Ubuntu 10.04 Lucid system that did nothing.
Some googling around showed up remarkably little. It seems everyone just uses the GUI installer and it does everything for you. There is not much help for the command-line user.
Anyway, eventually the answer did start to become clear. The locale data is kept in separate language packs. These are represented by various packages in the standard repository, with meta-packages to link things together.
The upshot is that you need to install the relevant language pack
Then set the default locale as desired
Log out and log in again to pick up the default locale. Then check it with
This should show the default locale set earlier.
I can now paste a smiley face ☺ into PuTTY and type a pound sign £ and that all works.
Note: The procedures documented in this article are not endorsed by XenVZ.co.uk. They come with no guarantees whatsoever. Following the procedures in this article could destroy your data, or leave you with a raft of important services stacked on top of a hopelessly unstable system. Proceed entirely at your own risk.
For Xen VPSs, XenVZ currently offers Ubuntu 8.04 Hardy and 9.04 Jaunty, but nothing later than that.
If you start with 9.04 Jaunty and try an out-of-the-box in-place upgrade to 9.10 Karmic, you find that your machine will no longer boot.
So if you want to use something later like 9.10 Karmic or 10.04 Lucid, you need to do something a bit cleverer.
For Xen VPSs, XenVZ uses a stock kernel which appears to be some version of 2.6.18 out of RHEL 5.something. This is all patched and updated and all fine for many purposes. This stock kernel is, by default, booted from outside the VPS and is used regardless of what is configured inside the VPS.
However Karmic's default boot configuration requires /proc/<process-id>/mountinfo, which I believe was a new feature for kernel 2.6.26.
To get Karmic working, we would either need to alter the boot configuration, or make the kernel provide the required feature.
Kernel 2.6.18 seems fairly ancient to me, so my approach would be to use a later kernel.
Fortunately, XenVZ now offer an "expert" feature for configuring one's own kernel via PvGrub/PyGrub. This can be turned on through a tick box in the control panel under "Custom Kernel".
It may be possible to use a kernel from Ubuntu, but for various reasons, I have gone down the path of using a kernel from Debian. (After writing the original version of this article, I switched the system over to an Ubuntu kernel and it worked fine; better in fact because it booted up with fewer warnings etc.. So it may be possible/better to use an Ubuntu kernel from the beginning. Please let me know if you get any success doing this.)
First guess might be the Debian 5.0 Stable "Lenny" kernel which is version 2.6.26. But this apparently has problems running as a domU under Xen.
The next guess I had was to use a kernel from Debian Testing "Squeeze", which would be a version 2.6.32 kernel.
Nicely for us, kernels nowadays seem to support Xen domU operation even in the "ordinary" kernels, so we don't need to go hunting around for a special Xen-domU-enabled kernel. (This seems to be related to "pvops" http://wiki.xensource.com/xenwiki/XenParavirtOps.) So we should be able to use the basic basic kernel from Squeeze and it should work.
So, our steps would be:
Set your VPS up with Ubuntu 9.04 Jaunty using the XenVZ web control panel.
Install any updates which have been published since the system image was made:
Download the deb package for the appropriate kernel from Debian Squeeze. This can be done using "wget" (though "wget" isn't installed by default so if it is a fresh system you will have to put it on (aptitude install wget)).
Install this kernel using "dpkg -i"
(This is lifted from http://wiki.debian.org/PyGrub) Create the environment needed for running update-grub
(This is a bit I added in the middle.) We need to run "update-grub" to generate /boot/grub/menu.lst. However, because the above kernel does not have the word "xen" in its name, "update-grub" will not recognise this kernel as suitable for Xen domU use, so ordinarily it skips it. There may be a good way of fixing this, but for now I just fudge "update-grub" to think all kernels are suitable for Xen domU use. Edit "/usr/sbin/update-grub", look for the bit that goes "is_xen=" and change it to "is_xen=1". (I've raised Bug 586756 against Ubuntu, and provided a patch.)
(This is lifted from http://wiki.debian.org/PyGrub) Create first /boot/grub/menu.lst based on the content of /boot
In the XenVZ web control panel, turn on "Power User" and "Custom Kernel".
In "/etc/event.d", copy the file "xvc0" to "hvc0", then edit "hvc0" and replace all instances of "xvc0" with "hvc0". This is needed because in the later kernel, the console device name changes from xvc0 to hvc0.
In "/etc/fstab", change "sda1" to "xvda1" and "sda2" to "xvda2". This is needed because in the later kernel, the block devices exposed through Xen get different names. Also you may want to check the sixth field of all records and make sure it is zero for anything which isn't a real filesystem. This is suggested because from a certain version of Ubuntu, it starts to try to fsck the swap partition and complains about not being able to find fsck.swap.
You should now be able to re-start the VPS and it should boot up on the new kernel.
Assuming it comes up, check that your swap is enabled (cat /proc/swaps), and check that console login access is working (to get console access, follow the instructions provided in the web control panel)
There may be other things we can do to clean this up further — please let me know if you have any suggestions.
If you ignored my suggestion to get console login access working earlier then stop and do it now. One day you will need it and when you need it, (a) you will really need it, and (b) you will not then be in a position to set it up. You need to check that your console access is working ahead of time so that it is ready and working for when you need it.
Once you have the new kernel, you should be able to upgrade to Ubuntu 9.10 Karmic. The procedure is outlined at https://help.ubuntu.com/community/KarmicUpgrades. In essence it goes as:
If you are currently on 9.04 Jaunty, it should suggest an upgrade to 9.10 Karmic. The upgrade will probably ask you about a network configuration file which has been modified. I took the new version of the file and it worked.
That should all run through and then ask you to re-boot. You should be fine to reboot at this point. When it comes back up you should then be on 9.10 Karmic.
I don't recall if it is Karmic or Lucid, but one of them changes how the console login access works relative to the previous version. So you may now want to check the contents of "/etc/init". You should have a file "tty1.conf". Copy this file to "hvc0", then edit it and change all instances of "tty1" to "hvc0". We then need to get init ("upstart"?) to re-read the configuration. I haven't figured out how to do this yet, but a re-boot will get that working soon enough.
Check that console login access is working.
Once we have 9.10 Karmic up and running, we can upgrade to 10.04 Lucid. This can be done in the same way as the upgrade to Karmic (do-release-upgrade).
Lucid seems to install "Plymouth" (a boot splash manager) by default, which is a bit pointless for a co-located VPS. Unfortunately it seems that some critical-looking things depend on Plymouth, so I didn't fancying uninstalling it. But we can disable Plymouth easily enough by moving its configuration files out of /etc/init:
Also, you may want to look at the kernel boot parameters in /boot/grub/menu.lst. You may see a line like:
(If I understand correctly, the UUID will be different for each system.)
You may want to remove the directives 'splash' and 'quiet'. I think 'splash' is to do with a splash screen, which is a bit pointless on a VPS. I think 'quiet' is probably to do with reducing the amount of chatter during boot-up, which is probably the opposite of what we want.
Again, check that console login access is working.
I also took the opportunity to disable the redundant "tty" entries in /etc/init, by moving them to /etc/init-disabled.
Since first writing the article, I discovered that we can use Ubuntu kernels. Using Ubuntu kernels makes it boot more smoothly. I only switched to an Ubuntu kernel at the end of the process, but it may have worked to use an Ubuntu kernel from the beginning.
Turns out that following the above approach results in a system which doesn't do UTF-8 by default. If you want UTF-8 support, you have to put that on yourself. See Setting up a default locale under Ubuntu 10.04 Lucid.
If you have any further information or suggestions, please let me know.
It seems that Dell Tech Support have replaced a layer of people with a layer of machines and as such whereas you could previously give your machine ID using the (alphanumeric) Service Tag to a person, you now need to give your machine ID to a machine, which means it needs to be the (numeric) Express Service Code.
This is no problem if you have the machine in question because the service tag sticker has both the (alphanumeric) Service Tag and the (numeric) Express Service Code.
However, if you had been noting only Service Tags from machines and storing those in your records, you might not have the (numeric) Express Service Code to hand and this may cause a problem.
It turns out that there is a relatively straightforward relationship between the Service Tag and the Express Service Code.
It seems that if you take the Service Tag and treat it as a base 36 number, then express that quantity as a base 10 number, and add hyphens in the right places, you get the Express Service Code.
The hyphens aren't crucial because you don't dial them, but if you want to match the existing codes exactly, it seems you need to add hyphens every three digits, but with the proviso that if we would otherwise end up with a single digit on its own, then we start with two digits instead of three.
Wanting to convert an existing file of service tags en masse, I came up with a little Perl program which would do it as a pipe filter:
perl -e 'while(<>){chomp; if(/^[0-9A-Z]{1,7}$/so){@a = split //; my %e; @e{"0".."9","A".."Z"} = (0..35); my $r = 0; while(@a){ $r = ($r * 36) + $e{shift @a}; }; @r = split //, $r; my @s; push @s, join "", splice @r,0,2 if ((@r % 3) == 1); push @s, join "", splice @r,0,3 while @r; $_ = join "-", @s; } print"$_\n";}'