More of the same?


Demonic mail breakage

Filed under: FAIL, Miscellaneous — Tags: , , , , , , , , — _ds_ @ 20:05

From the Demon Internet blog:

We recently told you that we’ll be migrating customers with Demon email services to a brand new, Microsoft Exchange based email platform. That time is almost here!

It is important that you regularly check the Demon Blog, the Demon Forum and the Demon Knowledgebase as we will use these to post the latest information about how the migration is going and how it may affect you.

Shortly we will be sending you important information that will enable you to migrate your email service. To ensure that you receive this information it’s essential that you can accept email to your Demon Postmaster email address (, as this is the address we will use to communicate important information such as your login details and migration date.

For the record, Demon’s current mail system has a rather unique extension in that you can collect all mail for your domain (domain) via POP3 but with envelope information intact. You can also collect for a specific local part (user+domain), again via POP3. In the absence of SMTP delivery (which I’d prefer), this is Quite Useful.

Problem is that they’re planning to break this useful working setup with an off-the-shelf Exchange system. Which requires that local parts are registered, else it ends up in ‘administrator’ and, it seems, without envelope information so that it can not be properly delivered.

There’s been a lot of debate in the demon.announce newsgroup about this.

I’ve responded to it as follows. I’m reproducing the text here, initially in case it was moderated away; and it has been.


I sometimes use finger to see what mail’s waiting.

I use arbitrary local parts in my email addresses. If I add a new one, then adding it to /etc/aliases should be sufficient – and, indeed, currently is. This is good. It’s simple, it works, why break it by requiring registration of local parts for which you want envelope information to be kept? For a start, it requires information to be kept in at least two places, and in different formats. (And if the registration page doesn’t work in a text-only browser and requires access via my Demon account, then it isn’t always going to be POSSIBLE to register a new local part when I create it.)

The corollary of this is that envelope information for ‘unregistered’ email addresses will be thrown away. This is just plain broken.

The current email setup is fine. It works. It does what I want. It’s part of the service FOR WHICH I’M PAYING.

The new one, from what I’ve read, doesn’t.

… with a followup, because another point was made in demon.service:

Also, what’s up with posting to demon.announce and/or demon.service? There are a good few of us who read these newsgroups.

And I wasn’t really aware of this ‘blog until I caught up with reading demon.service, and I’m unlikely to check what I’m unaware of (or, for that matter, go out of my way to read something in some place when there’s been a good method of communicating with us there for YEARS).

(Incidentally, the text box in which I’m typing this is too wide: part of it is obscured by the right-hand column of this page.)

They’re now advertising it as an improvement. I’m thinking about migrating to some other ISP – preferably one which still has some clue.


Geolocation: how to fake it or fix it in Chromium

Filed under: Desktop, Mobile, Software — _ds_ @ 14:06

After a little searching, I’ve found out how to set my location for desktop browsers without involving Google. There is sufficient detail there for any competent person to be able to appropriately configure Firefox, but it’s a bit lacking for Chromium and Google Chrome.

Quoting from the above page:

The way these geolocation services work is by requesting a file from Google which then responds with your location in JSON format. To fake this in Firefox, you can create a file on your computer with this text:

{"location":{"latitude":48.861426,"longitude":2.338929, "accuracy":20.0}}

You can find this location by locating it in Google Maps or any other maps program that supports Latitude and Longitude. Google maps generates a link that looks like the following:,2.338929&spn=0.011237,0.027874&z=16

In this case the first number is the latitude and the second the longitude.

The full name of the file should look, on GNU/Linux, something like /home/user/.config/location.txt.

To make Chromium respect your chosen location, you need to load ~/.config/chromium/Local State (on your common or garden GNU/Linux distribution etc.) and look for "geolocation" (complete with quotation marks); replace with the full path name of the file containing the JSON text describing your location, converted into a URL, so you’ll need to prefix with file:// and quote certain characters, e.g. spaces become ‘%20’ and, on Windows, backslashes become forward slashes. Using the above example name, you’ll end up with file:///home/user/.config/location.txt. Now save the file.

Do this while the browser is not running, else it’ll take no notice of your changes and will happily overwrite them.

While I couldn’t say for Google Chrome, I do expect that the only difference from Chromium is the file which you need to edit.

This allows me to properly attach my location to Google+ postings without having to rely on my phone, but it’s limited: I do still need to use the mobile browser version of G+ (which works fine in desktop browsers) if I want more control over the location, for example to use what Google call “your city-level location”.

(There is one error in the how-to, though: the example JSON text contains an extra number just before “longitude”.)


Wide browser windows

Filed under: Software — _ds_ @ 13:54

Is it just me, or do any of you lot hate wide browser windows too?

I’m putting up with horizontal scrolling (or zooming out, in some cases) here so that I can have the window width which I want – which allows me to open an X terminal alongside it, as it happens…

800 pixels is a reasonable minimum width, and anybody who thinks that 1024 pixels is a better choice or, worse, lets text be reformatted to the window width no matter how wide (without making some effort to constrain it to something reasonable) should be… I don’t know. Suggestions?

What has to be remembered here is that there are many devices out there with small displays:

  • Netbooks with 7″ panels
  • Smartphones

These typically have displays which are 800 pixels by 480 pixels (or possibly 480×800), and while the phones may be redirected to ‘mobile’ versions of the content, both they and netbooks may display the full site. It is true that many browsers, these days, have a zoom function, but it’s possible that the content may be rendered too small to read if the user has to use this to shrink it to fit the available screen space. (I can manage with quite small text, but that doesn’t mean that I necessarily want to.)

I mentioned, above, wide text. It’s particularly annoying to have to scroll back and forth horizontally just to be able to read the text (but again, zoom functionality); there are times when I’ve had to zoom out when reading a forum because of some large screenshot which the poster didn’t think to thumbnail. This is particularly fun when the screenshot is 1920×1080; consider that the largest monitors here are 1280×1024.


What to do?

Web designers: flexible width wins. Primary content which fits within a column at most 800 pixels wide wins, even if it loses in other ways. It may even be necessary to enforce a minimum width to prevent, for instance, a column of single-word lines… But, if you must allow it to be wider, constrain it to some suitable readable maximum. The CSS2 properties min-width and max-width help with these.

And, for un-thumbnailed images: one possible solution is max-width: 100%; which will, on most browsers, prevent it from widening its containing box; and another is overflow: auto; which may cause scroll bars.

It’s a minefield out there ☺


xine and WebM

Filed under: Media, Software — _ds_ @ 20:37

I’ve just this evening been pointed at WebM. It’s looking like the video format (VP8) will need a small amount of work to be supported in xine, but the container format (a Matroska subset) is essentially already supported, requiring only minor tweakage.

With any luck, it’ll take but a few days to sort out the VP8 support, so it should all be ready in plenty of time for 1.1.19 (which, as usual, will be ready “when it’s ready”).


Resolving screen size?

Filed under: Miscellaneous — _ds_ @ 15:26

$ xdpyinfo | grep -e screen -e dimension -e resolution
default screen number: 0
number of screens: 1
screen #0:
dimensions: 2560x1024 pixels (675x270 millimeters)
resolution: 96x96 dots per inch

How did, in what passes for normal usage, did resolution become confused with dimensions? Something to do with same dimensions (in pixels) but differing physical sizes?


Oh, for a user with clue… (or Lowest Common Documentation)

Filed under: Documentation, Software — Tags: , , — _ds_ @ 01:05

Now that that’s grabbed your attention… 🙂

Fortunately, many do seem to have some clue, or at least the capacity to absorb some clue, which is good; these ones, as we all know, are usually easy enough to deal with even when they file reports about distributor-specific bugs in the upstream bug-tracking system, sometimes without any indication whatsoever of what they’re actually using. (Clearly, we upstream people know exactly what the bug reporter is using and know exactly what differences are present in each and every distributors’ patched sources.)

I saw an example of this recently. It turned out to be a distributor-added bug: a wrapper script which used $@ instead of "$@", and those of us who grok shell stuff know what that means. (Oh go on, throw a filename containing a space at it. You know that you want to. Waka waka waka.)

But then there are ones like this…



xine-lib upcoming: VDPAU and BluRay

Filed under: Media, Software — Tags: , , — _ds_ @ 21:41

For those of you who regularly taint your kernels with nVidia code, VDPAU support has been merged into xine-lib. I created a copy of the xine-vdpau repository yesterday, first importing it (up to r275)¹ into a local Mercurial repository with the help of hgimportsvn and hgpullsvn (hgsvn).

Since the VDPAU support requires incompatible ABI changes, it needed to be ported to xine-lib 1.2; this is fine because the 1.2 API and ABI are not fixed yet². Consequently, it’s still a bit experimental, so it’s in a new (and temporary) 1.2 repository; it’ll go into the main 1.2 repository in due course.

(I can’t test the VDPAU code myself. I don’t have any nVidia graphics hardware, and nor do I want any: I sometimes use 3D and I don’t want the taint preventing me from upgrading to newer kernels as and when I choose and with whatever configuration options are appropriate for the hardware and I want to be able to report and occasionally fix kernel bugs without having to reboot without re-tainting the kernel just to get trustworthy kernel logs… so here’s hoping that VDPAU becomes supported by open-source drivers, and not only for nVidia hardware…)

Also, we’ve also got some basic BluRay support going into the next release in 1.1.17, which was released on 1 December. It won’t play discs as yet (and that probably won’t land in 1.1), but it should be able to handle decrypted files reasonably well. (No, I’ve not been able to test this either – yet. M2TS files are definitely playable, at least from hard disk.) There are still things missing; I’m currently expecting more patches.

Finally, if anybody wants to contribute to xine-lib and, hopefully, get involved in developing it (and I don’t just mean new features), by all means, send patches, fix bugs, acquire fame and fortune, get your name in lights the authors list…

¹ r276, the current revision at import time, is a bug fix and has nothing to do with VDPAU. As such, it went directly into 1.1.
² They will be when 1.2.0 is (eventually) released


St. Insert-Name-Here’s Park

Filed under: NUFC — Tags: , , — _ds_ @ 14:12

Well, okay, maybe not quite that bad. But close enough. (And it’s about time that I wrote something about this, now that things have calmed down a bit.)

You have to agree that the initial annoucement of Mike Ashley’s plans to invite sponsorship for the renaming of St. James’s Park was, well, a bit of a PR disaster.  The announcement was made, there was “a bit of” a backlash, then Derek Llambias (Newcastle United chairman, for both of you who’ve not yet heard of him) was wheeled out to say that the plan is “ @ St. James’s Park Stadium” (or something very similar), of which the general opinion seems to be “marginally better, but still unacceptable”.

Witness the crowd at NUFC home games (against Peterborough, for example): “get out of our club“, “stand up for St. James’s Park“, and no doubt a few more to come. (more…)


EeePCs, Ralink 2860, and Linux drivers

Filed under: EeePC, Kernel — Tags: , , — _ds_ @ 00:52

Things are looking up.

The rt2860sta driver is now working properly: the panic bug was fixed in Linux 2.6.32-rc5, and another bug which broke things for all but those of us whose EeePC has a Ralink 2860 has been fixed (the patch which caused it has been reverted), ready for 2.6.32-rc7. (The “panic bug” being the one which caused the kernel on any EeePC with a Ralink 2860 wireless network chip to panic, freezing the computer, when Fn-F2 was pressed while the wireless interface is associated with an access point.)

Also, (more…)


Intel SATA chipsets and AHCI

Filed under: Hardware, Kernel — Tags: , , , , — _ds_ @ 23:49

I’ve been playing with Matthew Garrett’s AHCI patch¹ (and discussing it with him on IRC), and we now have a new patch which seems to work a bit better: it handles a few possible failures and situations in which the quirk shouldn’t be activated, and also handles resume (for ICH7M; others need to be added and tested). (more…)

« Newer PostsOlder Posts »

Create a free website or blog at