Biella Coleman: New Zealand, a photo-round up
Kiwis have to be one of the cutest birds of all time. A bit chubby and clumsy looking, they are (to me, at least), walking, breathing icon of furry cuteness.
Kiwis have to be one of the cutest birds of all time. A bit chubby and clumsy looking, they are (to me, at least), walking, breathing icon of furry cuteness.
Kiwis have to be one of the cutest birds of all time. A bit chubby and clumsy looking, they are (to me, at least), walking, breathing icon of furry cuteness.
Why? I am pursuing this change because Debian has negotiated a revenue sharing deal with XXXXXI have nothing against ubuntu and I think it is a great distro. However, I believe that decisions like this go strongly against the principle of free software as we consider, in particular when it comes to putting the user first and not some cash deal. Forcing the user to choose for something because the company gave money for that is totally again this to me.
Just an update about
sgeps, because
it seems to have made a small stir (which is more than I expected).
emacs foo.gpg. Admittedly I found out while I
was developing sgeps, but I kept on my track anyway. The real
reason was that I was having fun, but I could also mention that
sgeps doesn't store data unencrypted on disk, not even
temporarily. I'm not sure about vim foo.gpg. (Update: Joey
Hess telle me it does the right thing.) Anyway, I don't want to
fire up an editor (or switch to an already opened one) just to get a
password.pwman too. My script started as
pwman.pl but it was renamed later. I like the simplicity of
sgeps better, especially the lack of any UI besides the CLI, but
pwman is probably good in its own way, but it doesn't fit my usage
pattern.sgeps is now packaged for Gentoo
Linux.sgeps --delete.
Thanks to him!sgeps should be able to store
notes as well as passwords. That wasn't a requirement I initially
had, but I won't reject the patch if it comes He also argues that
it should be able to push the password into the X11 paste buffer.
Again, why not, if it doesn't break anything.
I tried switching from identi.ca to
brainbird today, when my always present
frustration with 140 character limit in microblogging boiled over. Again.
In the process, I've found some warts in the OpenMicroblogging system,
beyond its obsession with fitting into an obsolete sideband communication
medium that I will never actually use.
Rant mode on.
Let's assume that OpenMicroblogging catches on, in a big way, and we're all
using it in 10 years. So, it will be something like email. And its
federated design allows for that; there can be multiple servers that
communicate, and so on. (Which is a very good thing, compared to the
twitter monoloth.)
But: How many times have you changed your email address? When you did,
you probably set up a .forward for the old email address, and emailed
some people from the new address to let them update their address book,
and it was not a big deal. But the experience when changing an
OpenMicroblogging site is not the same. You have to go out and re-follow
everyone. For each person, you have to go through a multiple screen
(OAUTH) process. This process may not even be automatible.
Second problem is that OpenMicroblogging does not use addresses. So to
talk to me, one uses @joey'. It's not clear to me how sites determine
whether to direct that to joey@identica or to joey@brainbird. Seemed like,
if I switched to brainbird, I would need to pick a new username, to avoid
having to check both places.
Finally, the
OpenMicroblogging spec,
while really quite a neat approach to piggyback on OAUTH,
has some absurd limits. 140 characters for a biography. Even the limit
for one's full name is longer than that. Absurd. Suprisingly, no 140
character limit on messages actually exists, that's just a recommendation.
But it's unclear how a system that sends a longer message interoperates
with systems that use shorter messages. Probably the message will be
truncated. And there is no way in the protocol to discover the message
limit of a remote system.
All in all, I think I prefer RSS, or Google Wave, or even IRC from a protocol
perspective. And from a usability perspective, Facebook does not have
absurd message limits, and most people read my messages there anyway.
Meh.
Lucas asks about how free the N900 is, whether he can download and
recompile and reflash. I'll try to answer some of those questions.
No, you can't download all the source. Part of it is just not open.
I am not privy to Nokia's decisions on why or why not to open up, but
it seems like the user interface bits are only partially open. Hildon
itself is open so you can poke at widgets and see how those work. The
address book is not open. The telepathy component that talks to the
cellular modem is not open.
As for having to accept EULAs, I honestly don't remember accepting one
of those, but I'm not going to say there are none. There's at least
one which is every time you install a package where you have to check
a box saying "Yes, I know this package is third party and will not sue
Nokia if it causes my house to burn down, my wife to divorce me or
causes somebody to steal the car". It's annoying, but I'm willing to
live with it.
The contents of apt's sources.list is:
deb https://downloads.maemo.nokia.com/fremantle/ssu/apps/ ./
deb https://downloads.maemo.nokia.com/fremantle/ssu/mr0 ./
deb https://downloads.maemo.nokia.com/fremantle/ovi/ ./
deb http://repository.maemo.org/extras/ fremantle free non-free
deb http://repository.maemo.org/extras-devel/ fremantle free non-free
(technically, it comes from
/etc/apt/sources.list.d/hildon-application-manager.list, not
sources.list.)
I believe the built-in applications are generally not free, so
rebuilding everything that is free will for instance leave you without
any address book UI, the built-in map application or camera. Sadly,
the X driver is also proprietary, so you won't be able to see anything
either.
I don't think you can usefully install another free distro on the
N900. You might be able to, at some point, assuming somebody goes to
the effort.
The last question is "- Besides the non-free telephony stack, are
there any other antifeatures I should be aware of?". The telephony
stack is implemented around Telepathy, which is LGPL-ed free software.
While it's correct that telepathy-ring (which talks to the cellular
modem), the call UI and most of the address book are proprietary, the
rest of Telepathy is free. There are SIP and XMPP connection managers
that are free, and you can install more connection managers for MSN,
IRC and so on.
Also, I think it's important to emphasise that the telephony stack
does not contain any antifeatures. The closest thing you would be
able to find is probably the restriction to one active and one held
call at the same time, but as one of the developers said: "That's to
prevent the UI from going mad".
While I like to tout the N900 as a free phone, it is in no way
completely free. Large parts of it are free, and almost as
importantly: most of the programming interfaces are free and at least
somewhat documented, so if somebody wants to replace the built-in
camera application with a free one, they can replace the DBus
interface that the camera app provides. Ditto for maps applications,
the address book and so on.
Coming to New Zealand for an extended period of time, I figured
it would make sense to purchase a prepay mobile plan to make it
easier to mix with locals. Not knowing better, I went with Vodafone, which I whole-heartedly
regret: their website is a massive pain in the ass, their price
plans
completely over the top, and their customer service
representative incompetent and unfriendly.
My latest experience eclipsed all previous encounters, and makes
me want to tell you about it:
Between all the obscure add-ons Vodafone threw at me when I
bought this SIM card, two weeks ago I couldn t figure out how my
balance had decreased from $30 to $0 when I rarely ever made
calls.
I wrote an e-mail to their customer service hotline, and it took
them a week to get back to me, with the following text:
Due to being a Prepay Customer, unfortunately usage details are not available as per terms and conditions. I have although checked your usage and can confirm that all charges are correct.Obviously, I wasn t going to accept this claim of omniscience, so when last weekend, $20 disappeared over the course of a day, that was the catalyst for me to reopen the ticket and reply along the lines of:
Only I know when I used my phone and thus only I can determine whether the charges are correct. Please show the full records to me, or elseThis seemed to convince the representative, and 8 messages and 11 days after my initial request, I was told I could request the records at $5/30 records. Yes, you read that right: they wanted to charge me to view the records. I thus replied:
I am NOT willing to pay for that. If you are unable to comply with my desire for transparency, then I shall terminate the contract and make sure to inform the media as well as the consumer institute of this conduct. As stated previously, I shall also consult with a lawyer. Charging consumers to view data that is obviously available is a strong indication that you do not want me to see it. I can t imaging why this would be the case other than the data being inconsistent with reality.That worked, and I finally got an Excel sheet with my usage data, which allowed me to track down the depletion of my account: to lure customers in, they promise free calls to other Vodafone numbers for the first four weekends. There are three problems with that though:
I received a surprising 13 responses to my
previous post,
which was certainly more than I expected and is one reason it's taken me a few
days to follow up on it. (How do you pick someone from a group of 13 people
based on just a paragraph or two? Clearly I'd like for someone to help all of
these people get involved in Debian, but to do so solely by myself would be
making a commitment that I just don't have time to come through on. So, it ends
up being quite arbitrary. I pick who I think I'd most like working with and
could make the most out of the opportunity, and even that is an arbitrary
judgement based on very little.)
One question asked by one of the people who emailed me was, "Why did you ask
for someone who isn't involved in Debian already and who doesn't necessarily
have the technical skills needed?"
The answer to this question has several facets.
For one, people already involved in a free software project tend to be busy
people. The workload in projects tends to be concentrated in few hands, and
many of those people who are already involved in a project don't need or want
any more work. So, asking for someone not already involved in Debian increases
the pool of people who might respond to such a request and actually be able to
follow up on it.
While this a valid reason, it still doesn't explain why I didn't just say,
"it's okay if you're not already involved in Debian or don't know python" and
not state a preference as to the skill level of the person who would respond to
such a request.
I did, however, have a specific reason for stating my preference. I asked
specifically for someone who wasn't already involved in Debian and who didn't
necessarily know python or consider themselves a competent programmer because I
wanted to encourage people who don't consider themselves to already know
enough to be a useful comaintainer to contact me. I've picked up a lot from
following Geek Feminism on what sort of language
turns minority groups like women away, and I wanted to ask in such a way that
it didn't turn away people who aren't good at self-promotion or who are less
sure of their skills, or who don't yet have the skills, men and women alike.
Even I still sometimes internally question my own competence as a programmer,
and my self-confidence has increased over the past few years.
(For the curious, the responses I received were, at my guess, 85% male, 15%
female. Whether that's a success or not depends on the demographics of those
who read the post, but it is better than the ~98% male involvement in the
FLOSS world altogether.)
And I do think it's more of a contribution to the project to help someone new
get involved than to try to convince someone who's already overcome the barrier
to entry to take on some more work. We'll see how it turns out in the end. I
have high hopes. (No pressure, soon-to-be-selected mentee.)
I know this is quite premature as we're just about to release 3.3, however
development on 3.4 has already started in SVN and we've already implemented
more than 20 requests from our features tracker. This is even bigger
number than release 3.3 will have!
Well the fact is that most of these things are cosmetic or tiny improvements,
on the other side some of them were requested for very long time (the oldest
one currently dates to 2003).
The new features bring things such as direct blob download (thing we definitely
should have earlier), links to documentation for SQL commands in highlighted
SQL (what was quite easy, but nobody requested such thing and I added the
feature after seeing that Adminer does this), possibility to directly
bookmark most pages or exporting user privileges. See ChangeLog for more
detailed list of features.
You can try all new features on our demo server.
In the last few days, I found the time to spend some with KVM and libvirt. Unfortunately, there is a subject that I
haven t yet found a satisfying solution: Naming of block devices in guest instances.
This is surely a common issue, but solutions are rare. Neither an article on Usenet (in German) nor the German version
of this blog article has found solutions for the main question. I should have written this in English in the first place
and am thus translating from German to english, hoping that there will be some answers and suggestions.
KVM is quite inflexible when it coms to configure block devices. It is possible to define on the host, which files or
whole devices from the host should be visible in the guest. The documentation suggests that devices should be brought
into the guest with the virtio model, which needs suppport in the guest kernel. Importing a device as emulated ATA or
SCSI device brings a performance penalty.
The devices brought into the guest via virtio appear in the guest s dev as /dev/vd<x> and do also have their
corresponding entries in /dev/disk/by-uuid and /dev/disk/by-path. The vd<x> node is simply numbered in consecutive
order as hd<x> and sd<x>. /dev/disk/by-uuid is the correct UUID of the file system found on the device, at
least if it s a block device partitioned inside the guest and formatted with ext3 (I didn t try anything
else yet). The terminology of the /dev/disk/by-path node is not yet understood, and I am somewhat reluctant to assume
the PCI paths of emulated hardware as stable.
Looks like I am forced to configure inside the guest when I have changed the host s mass storage system (for
example, after migration to a different file system or after new block devices have been added) to accommodate for the
new order of the /dev/vd<x> or to have the UUID correctly configured. This is like calling for configuration
errors.
This is a reincarnation of the same issue that has been killed by LVM on Linuxes running on bare metal :
The block device itself has a mnemonic name which is constant even in migration and copy actions. This works without
file-system specific stuff like UUID or label, and wouldn t even be possible with a UUID (which won t be
unique in this case). The mnemonic names of LVs are also available when the data is directly written to the raw device
such as a CNFS buffer of a news server.
I would love to have something like a paravirtualized device mapper interface which would allow to say in
the host s configuration which of the host s LVs should be visible in the guest with which name in
/dev/mapper. That way, the guest s configuration could remain stable during data wrangling operations on the
host.
One solution is to have a single LV for each guest and import this LV as /dev/vda into the guest. /dev/vda would then
be partitioned like a real disk and have its own LVM installation. This would however need kpartx if one wants to access
the data from the host, and loses flexibility when resizing file systems.
These issues appear in every installation of KVM virtualization, and I would expect that there are gazillions of other
possible solutions. I am interested in knowing how other people have tackled this issue and whether there are more
possiblity that I haven t thought of before. Maybe there is a solution that doesn t leave me with the
feeling of having implemented something ugly. Does the interface between the host s KVM and the guest s
device mapper that I have been dreaming of maybe exist. Or is there any other possibility of configuring the device
node s name in the guest Linux on the host side?
Whoa.
Kim Clijsters, Belgium's number 1 female tennis player of the moment,
just got booted out of the Australian Open by Nadia Petrova. Not what
I'd expected especially not with this kind of score; 6-0 6-1. To
call this "unexpected" would be a severe understatement.
Seriously.
That leaves Belgium's hope with Justine Henin or Yanina Wickmayer. I
say "or", because they'll next meet eachother in Melbourne. Sounds like
an interesting match, indeed.
$ gcc -g -shared -o libtest.so libtest.c $ objcopy --only-keep-debug libtest.so libtest.debug $ objcopy --add-gnu-debuglink=libtest.debug libtest.so $ objdump -s -j .gnu_debuglink libtest.so libtest.so: file format elf32-i386 Contents of section .gnu_debuglink: 0000 6c696274 6573742e 64656275 67000000 libtest.debug... 0010 52a7fd0a R...
$ readelf --wide --sections ./libtest.so grep build [ 1] .note.gnu.build-id NOTE 000000d4 0000d4 000024 00 A 0 0 4 $ objdump -s -j .note.gnu.build-id libtest.so libtest.so: file format elf32-i386 Contents of section .note.gnu.build-id: 00d4 04000000 14000000 03000000 474e5500 ............GNU. 00e4 a07ab0e4 7cd54f60 0f5cf66b 5799b05c .z.. .O .\.kW..\ 00f4 2d43f456 -C.V
uint32 name_size; /* size of the name */ uint32 hash_size; /* size of the hash */ uint32 identifier; /* NT_GNU_BUILD_ID == 0x3 */ char name[name_size]; /* the name "GNU" */ char hash[hash_size]; /* the hash */
(gdb) show debug-file-directory The directory where separate debug symbols are searched for is "/usr/lib/debug".
$ objdump -s -j .note.gnu.build-id /bin/ls
/bin/ls: file format elf32-i386
Contents of section .note.gnu.build-id:
8048168 04000000 14000000 03000000 474e5500 ............GNU.
8048178 c6fd8024 2a11673c 7c6a5af6 2c65b1b5 ...$*.g< jZ.,e..
8048188 d7e13fd4 ..?.
... [running gdb /bin/ls] ...
access("/usr/lib/debug/.build-id/c6/fd80242a11673c7c6a5af62c65b1b5d7e13fd4.debug", F_OK) = -1 ENOENT (No such file or directory)
This is the story of a weirdly unfriendly/non-compliant IMAP server, and some nice interactions that arose from a debugging session around it. Over the holidays, i got to do some computer/network debugging for friends and family. One old friend (I'll call him Fred) had a series of problems i managed to help work through, but was ultimately basically stumped based on the weird behavior of an IMAP server. Here's the details (names of the innocent and guilty have been changed), just in case it helps other folks in at least diagnosing similar situations. the diagnosis The initial symptom was that Fred's computer was "very slow". Sadly, this was a Windows machine, so my list of tricks for diagnosing sluggishness is limited. I went through a series of questions, uninstalling things, etc, until we figured it would be better to just have him do his usual work while i watched, kibitzing on what seemed acceptable and what seemed slow. Quite soon, we hit a very specific failure: Fred's Thunderbird installation (version 2, FWIW) was sometimes hanging for a very long period of time during message retrieval. This was not exhaustion of the CPU, disk, RAM, or other local resource. It was pure network delay, and it was a frequent (if unpredictable) frustrating hiccup in his workflow. One thought i had was Thunderbird's per-server max_cached_connections setting, which can sometimes cause a TB instance to hang if a remote server thinks Thunderbird is being too aggressive. After sorting out why Thunderbird was resetting the values after we'd set them to 0 (grr, thanks for the confusing UI, folks!), we set it to 1, but still had the same occasional, lengthy (about 2 minutes) hang when transfering messages between folders (including the trash folder!), or when reading new messages. Sending mail was quite fast, except for occasional (similarly lengthy) hangs writing the copy to the sent folder. So IMAP was the problem (not SMTP), and the 2-minute timeouts smelled like an issue with the networking layer to me. At this point, i busted out wireshark, the trusty packet sniffer, which fortunately works as well on Windows as it does on GNU/Linux. Since Fred was doing his IMAP traffic in the clear, i could actually see when and where in the IMAP session the hang was happening. (BTW, Fred's IMAP traffic is no longer in the clear: after all this happened, i switched him to IMAPS (IMAP wrapped in a TLS session), because although the IMAP server in question actually supports the STARTTLS directive, it fails to advertise it in response to the CAPABILITIES query, so Thunderbird refuses to try it. arrgh.) The basic sequence of Thunderbird's side of an initial IMAP conversation (using plain authentication, anyway) looks something like this:
1 capability 2 login "user" "pass" 3 lsub "" "*" 4 list "" "INBOX" 5 select "INBOX" 6 UID fetch 1:* (FLAGS)What i found with this server was that if i issued commands 1 through 5, and then left the connection idle for over 5 minutes, then the next command (even if it was just a 6 NOOP or 6 LOGOUT) would cause the IMAP server to issue a TCP reset. No IMAP error message or anything, just a failure at the TCP level. But a nice, fast, responsive failure -- any IMAP client could recover nicely from that by just immediately opening a new connection. I don't mind busy servers killing inactive connections after a reasonable timeout. If it was just this, though, Thunderbird should have continued to be responsive. the deep weirdness But if i issued commands 1 through 6 in rapid succession (the only difference is that extra 6 UID fetch 1:* (FLAGS) command), and then let the connection idle for 5 minutes, then sent the next command: no response of any kind would come from the remote server (not even a TCP ACK or TCP RST). In this circumstance, my client OS's TCP stack would re-send the data repeatedly (staggered at appropriate intervals), until finally the client-side TCP timeout would trigger, and the OS would report the failure to the app, which could turn around and do a simple connection restart to finish up the desired operation. This was the underlying situation causing Fred's Thunderbird client to hang. In both cases above (with or without the 6th command), the magic window for the idle cutoff was a little more than 300 seconds (5 minutes) of idleness. If the client issued a NOOP at 4 minutes, 45 seconds from the last NOOP, it could keep a connection active indefinitely. Furthermore, i could replicate the exact same behavior when i used IMAPS -- the state of the IMAP session itself was somehow modifying the TCP session behavior characteristics, whether it was wrapped in a TLS tunnel or not. One interesting thing about this set of data is that it rules out most common problems in the network connectivity between the two machines. Since none of the hops between the two endpoints know anything about the IMAP state (especially under TLS), and some of the failures are reported properly (e.g. the TCP RST in the 5-command scenario), it's probably safe to say that the various routers, NAT devices, and such were not themselves responsible for the failures. So what's going on on that IMAP server? The service itself does not announce the flavor of IMAP server, though it does respond to a successful login with
You are so in, and to a logout with
IMAP server logging out, mate. A bit of digging on the 'net suggests that they are running a perdition IMAP proxy. (clearly written by an Aussie, mate!) But why does it not advertise its STARTTLS capability, even though it is capable? And why do some idle connections end up timing out without so much as an RST, when other idle connections give at least a clean break at the TCP level? Is there something about issuing the UID command that causes perdition to hand off the connection to some other service, which in turn doesn't do proper TCP error handling? I don't really know anything about the internals of perdition, so i'm just guessing here. the workaround I ultimately recommended to Fred to reduce the number of cached connections to 1, and to set Thunderbird's interval to check for new mail down to 4 minutes. Hopefully, this will keep his one connection active enough that nothing will timeout, and will keep the interference to his workflow to a minimum. It's an unsatisfactory solution to me, because the behavior of the remote server still seems so non-standard. However, i don't have any sort of control over the remote server, so there's not too much i can do to provide a real fix (other than point the server admins (and perdition developers?) at this writeup). I don't even know the types of backend server that their perdition proxy is balancing between, so i'm pretty lost for better diagnostics even, let alone a real resolution. some notes I couldn't have figured out the exact details listed above just using Thunderbird on Windows. Fortunately, i had a machine with a decent OS available, and was able to cobble together a fake IMAP client from a couple files (imapstart contained the lines above, and imapfinish contained 8 LOGOUT), bash, and socat. Here's the bash snippet i used as a fake IMAP client:
spoolout() while read foo; do sleep 1 && printf "%s\r\n" "$foo" ; done ( sleep 2 && spoolout < imapstart && sleep 4 && spoolout < imapfinish && sleep 500 ) socat STDIO TCP4:imap.fubar.example.net:143To do the test under IMAPS, i just replaced TCP4:imap.fubar.example.net:143 with OPENSSL:imap.fubar.example.net:993. And of course, i had wireshark handy on the GNU/Linux machine as well, so i could analyze the generated packets over there. One thing to note about user empowerment: Fred isn't a tech geek, but he can be curious about the technology he relies on if the situation is right. He was with me through the whole process, didn't get antsy, and never tried to get me to "just fix it" while he did something else. I like that, and wish i got to have that kind of interaction more (though i certainly don't begrudge people the time if they do need to get other things done). I was nervous about breaking out wireshark and scaring him off with it, but it turned out it actually was a good conversation starter about what was actually happening on the network, and how IP and TCP traffic worked. Giving a crash course like that in a quarter of an hour, i can't expect him to retain any concrete specifics, of course. But i think the process was useful in de-mystifying how computers talk to each other somewhat. It's not magic, there are just a lot of finicky pieces that need to fit together a certain way. And Wireshark turned out to be a really nice window into that process, especially when it displays packets during a real-time capture. I usually prefer to do packet captures with tcpdump and analyze them as a non-privileged user afterward for security reasons. But in this case, i felt the positives of user engagement (how often do you get to show someone how their machine actually works?) far outweighed the risks. As an added bonus, it also helped Fred really understand what i meant when i said that it was a bad idea to use IMAP in the clear. He could actually see his username and password in the network traffic! This might be worth keeping in mind as an idea for a demonstration for workshops or hacklabs for folks who are curious about networking -- do a live packet capture of the local network, project it, and just start asking questions about it. Wireshark contains such a wealth of obscure packet dissectors (and today's heterogenous public/open networks are so remarkably chatty and filled with weird stuff) that you're bound to run into things that most (or all!) people in the room don't know about, so it could be a good learning activity for groups of all skill levels. Tags: debugging, imap, perdition, wireshark
Next.