Role addresses

Jan 7, 2009 / 0 comments

When I ran Black Cat we preferred customers to use role addresses (e.g. support@, sales@) rather than contact us directly. This had the advantage that more people got the mail, increasing the likelihood of it getting answered swiftly. However some people preferred to email one of us directly, even for trivial matters. Having a preference for using role addresses myself I can sort of understand why people did this; often there is a poor or non existent response from a company's generic email addresses, leaving no choice but to try and email a known contact. However in our case it would have led to a poorer chance of timely response.

These days I don't have to worry about these things in quite the same way, but there are a few things I'm on what could be considered a "role" address for. And still I get emailed directly about things. Which is still annoying. So please, if you are considering emailing me about something that isn't personal, consider whether you should be using a role address rather than emailing me directly.

(This semi rant brought to you as a way of testing if my MovableType upgrade worked)

Debian: King of procrastination

Dec 15, 2008 / 0 comments

Once again Debian is close to release. And once again we're trying to find ways to avoid doing so. Using a technique we've employed before; firmware.

Social Contract #4 states that "Our priorities are our users and free software". The hard liners believe that it's in our users' best interests that we ensure Debian is 100% Free, whether that be regarding software, documentation or firmware. In the long run I think they're right. Access to firmware source (assuming that there's also access to suitable tools for building it and producing an image the hardware will accept, which is a fairly big assumption) enables us to continue supporting and improving hardware support long after a manufacturer has discontinued a device. It enables us to understand the behaviour of a new device better (allowing better support which makes it a more attractive purchase). It potentially lets us appropriate a device for new and exciting purposes the manufacturer never imagined (which may again increase the sales of the device). Access to firmware source is a good thing in the long term, for the consumer, the driver author and the manufacturer.

In the short term we I think we need to be pragmatic. We can say that we won't release until all non-free firmware is purged, but who knows how long that will take, and once we've done so how much hardware will we actually be able to support out of the box? What benefit is it to our users if we ship them a distribution that doesn't support their hardware and is already out of date because we spent so long removing that support? Wouldn't we be better to say "We're aware of some firmware issues. We're going to keep working on spliting such blobs out to their own easily installable packages that live outside main. We promise to continue improving the situation for each release (as we have already done since etch), but in the interests of our users we will not hold up a release at this stage of the process." Obviously plenty of people disagree with that, but I don't believe that pragmatism is against the Social Contract and I'd like to think that even our users who are fervently against firmware blobs would accept that there's a tradeoff to be had against release dates.

Anyway. I doubt I've changed anyone's mind with the above, so I'm going to go and destack the dishwasher and reply to the latest mail from my NM.

We need a STFU option

Dec 8, 2008 / 0 comments

The Debian Project recognises that on occasion the General Resolution process is dominated by a vocal minority of the project members, while the majority are uninterested in the topic under discussion. Without wishing to curtail the democratic process it is felt that it should be possible for the silent majority to indicate its desire to move on from the topic of a GR rather than continuing to rehash the same arguments ad infinitum. In order to facilitate this the project resolves to add a further option to all ballets, "No Further Discussion".

It is hoped that in the event of the "No Further Discussion" option being the winner of any vote that the project as a whole will accept that discussion of the subject of the vote is not considered to be a worthwhile use of project time or resources, and that we should therefore concentrate on more important matters.

(I thought about signing this post, but decided against it)

Perl regex help

Nov 28, 2008 / 0 comments

Dear Lazyweb, please put me out of my misery.

I have a string that looks something like:

a b c foo {0 1 2} fred {3 4 5} {{5 4 3} {2 1 0}} quux

I want to output:

a
b
c
foo
{0 1 2}
fred
{3 4 5}
{{5 4 3} {2 1 0}}
quux

(actually I want each line to be an array element, but that's obviously easy)

Can I do this with a Perl regex? Originally I thought I was going to have to walk the string like I would in C, but some playing around (and local help) got me to:

my $match = qr/(?:\s*[^\{\}\s]+\s*|\{(?R)\})/;

while ($cur =~ m/($match)\s+(.*)/o) {
        print $1, "\n";
        $cur = $2;
}

which sort of gets me there, except I get

{0 1 2} fred {3 4 5} {{5 4 3} {2 1 0}}

as one line instead of 4.

What obvious thing am I missing here?

FDMI success

Nov 4, 2008 / 0 comments

This is the point where I should be writing something witty and intelligent about the election going on across the pond, but I can't think of anything worth saying. If you can, go and vote. Even if you think your side is going to win, go and bloody do it anyway.

Anyway. Today I achieved FDMI success; my code successfully registered my test cluster against the fabric switch it's connected to and reported various bits of information about itself. Hardly earth shattering but does at least indicate that I'm beginning to understand some details of Fibre Channel at the packet level and how to make our code send/receive them. Go 'bama me.

(FDMI is the Fabric Device Management Interface and a way for Fibre Channel devices to report things like their manufacturer, serial number, OS, HBA model and driver/firmware versions to a management controller on the switch fabric. It's not a complex protocol in any manner, but there's a distinct lack of clear Fibre Channel documentation around that's at a lower level than "So you want to hook up a SAN?")

subscribe via RSS