Older blog entries for Omnifarious (starting at number 138)

My first Erlang program!

I put my first Erlang program in a pastebin. It's a concurrent prime sieve. Likely not the most efficient way to do things, but I'm still all pleased with myself. :-)

I may or may not choose to program more sophisticated things in Erlang, but I figured a passing familiarity was in order. Especially since I'm thinking of using CouchDB for something and it's written in Erlang. While knowing Erlang isn't necessary to understand CouchDB, I figure that it certainly can't hurt.

Syndicated 2009-11-07 22:56:33 (Updated 2009-11-07 22:58:10) from Lover of Ideas

NP completeness and the singularity

In many books about the singularity, the idea comes up of having your thought processes run on some interesting and imaginative substrate. Say, as an emergent property of a flock of pigeons. While this might well be possible, I think NP completeness places some hard limits on exactly what an external observer can determine about such systems.

There is an interesting problem that might be NP complete called the graph isomorphism problem. The graph isomorphism problem deals with proving that two different graphs have a one-to-one mapping showing them to be a simple transformation of each other.

So, if you have two different entities claiming to be the same entity running on a different substrate it's very hard to tell if they really are unless they tell you the mapping.

A plot element in some post-singularity novels is the idea of someone hiding themselves in various places by having themselves run on a wide variety of unusual substrates. A sort of steganography of consciousness. If the graph isomorphism problem is NP complete, then finding entities of human-level complexity who are doing this is likely practically impossible. Even the resources of a matrioshka brain are likely not enough to do the computation required to find them.

Syndicated 2009-10-16 19:09:29 from Lover of Ideas

13 Oct 2009 (updated 14 Oct 2009 at 04:14 UTC) »

Sexism in the FOSS movement...

This question, generalized to the software field as a whole has been of great interest to me for a long time. And the main conclusions I've come to are that the whole topic is very complex and nuanced and there aren't a lot of simple answers.

Most interesting to me are the knee-jerk reactions, many of which are in evidence in this articles on Slashdot titled "FOSS Sexism Claims Met With Ire and Denial".

I will address a few of them here...

Your race or gender shouldn't matter on the Internet since everybody is just text.

Well, that's true, to a point. But the real truth is that everybody uses pronouns for themselves or others. And we have one set of names we usually use for girls, and another set for boys. Gender is a deep, built-in aspect of almost any communication.

It is, of course, possible to convincingly fake being a boy, or fake being white. But why should you have to? Why should you have to hide some important part of your identity in order to be taken seriously?

Open Source is a meritocracy.

Well, yes and no. Women in Open Source stick out like a sore thumb because there are so few of them. One source I read quotes a figure of 1.5% for the percentage of women involved and given my observation that figure is completely believable. If you are a girl, you will be treated differently simply because you are such a novelty. Anybody who denies this is denying a basic fact about how people act.

Feminists ate my dog!

Well, OK, not exactly. But I see a large class of comments about how some random (often academic) feminist said some really awful thing, and how now their whole view of feminism is tainted.

First, open your eyes. I agree that statements like "All men are rapists." are pretty hateful and certainly not at all helpful. But for many statements of that ilk it's difficult to tell if a particular feminist actually said that, or if someone just put words in his or her mouth after misinterpreting what was written. Also, in my experience, most people who identify themselves as feminist do not hold views that are even remotely similar to statements like that. Most are reasonable people who just think women should have the same opportunities and rights as men.

Secondly, the issue isn't even related. So, some random feminist said something you find really distressing. What's that got to do with sexism in the FOSS movement? Are you trying to say it doesn't exist (if that's true, why only 1.5% women?)? Are you trying to say that your perception of people who identify themselves as feminist justifies mistreating all women? That's pretty messed up. Really, this is just a distraction so you can avoid thinking about the actual problem.

Women should just buck up, take it like a man and stop whining!

Well, many of them do. But not pointing out a problem doesn't help deal with the problem now does it?

And the problem exists. The 1.5% figure isn't a lie. While I'm willing to entertain the idea of a biological difference of some kind generally predisposing women or men towards different things, I'm not willing to believe that any such difference would result in such a profound split. Maybe, just maybe a 60%<->40% split. Maybe. But most definitely not 1.5%<->98.5%. Only cultural and social forces could create such a profound split.

My favorite mental picture here is the overlapping bell curves. Sure the averages may be a little different, but many more people live in the place where the bell curves overlap than live in the place where only members of one distribution live.

Those, I think, are the major knee-jerk responses I see. None of them are particularly helpful for actually confronting the issue. They are all evasions or denials of one kind or another.

Among people who recognize the problem, there are a number of knee-jerk solutions I see proposed. Many of them have the effect of banishing sexuality and gender identity from increasingly widening spheres of human interaction. I don't think the answer lies that way at all. I think it is both bad for people, and not very workable.

People are sexual, and that is a core part of who we are. Men and women exist and are different in important ways. Banishing sexuality or gender identity is a denial of both of those facts.

One technique I wish women used more is table turning. Men are not frequently depicted as sexual objects and women are. If you notice that professional presentations are depicting women as sexual objects, create some of your own that do the reverse. If you're called on it, point to the other presentation and ask why it was OK for them.

I don't think that kind of objectification is to be encouraged in professional presentations. It detracts from the subject matter. But men will have a tendency to ignore it or tut-tut about it without doing anything. Once men are at the uncomfortable end of things, maybe we'll get it.

Syndicated 2009-10-13 07:08:48 (Updated 2009-10-13 18:09:54) from Lover of Ideas

Well, my collaborator wants a patent :-(

And the only way I'll let myself be associated with a patent is if it's clear the patent will never be asserted against any software meeting the open source definition or meeting the free software definition. This is a concession he's unwilling to make. In particular, he wants some kind of definition for 'commercial' against which the patent can be asserted.

Oh, well. I'm going to generously allow him to use it in proprietary software if he so chooses. I'm trying to think up a set of conditions that will make sure the source never appears in public so nobody is ever tempted to put themselves in the way of a patent, should he choose to file one.

He thinks I'm completely nuts, and also thinks my principles are antithetical to his ability to make a living. *sigh* That's not how things work. The only power in ideas is if they're shared widely and freely.

I think the idea is a neat idea, but not that neat. Like all ideas it builds on and incorporates existing ones. For all I know, someone has already thought of doing something like it. I know at least one project of mine was something close.

Syndicated 2009-09-15 21:21:47 (Updated 2009-09-15 21:25:08) from Lover of Ideas

Yay! It works!

Because of an agreement with my collaborator I have to keep a bit quiet about exactly what it is for now. But I've been working hard on it for the past 4-6 weeks or so. And it's mostly in that "It'll crash at the drop of a hat (by design) but the major functionality works." state, so it needs a lot of polishing before I'll really consider it worthwhile.

It's an implementation of a really interesting idea related to how pure functional programs handle I/O. More than that, I'm not going to share just yet. :-)

I will say that there is a lot of potentially re-usable C++ code in there for wrapping up various Unix and networking concepts in a nice pleasant wrapper. I've always thought that the way Python wraps all that stuff up in a framework that throws exceptions is very nice for rapid prototyping, and also nice for cleaner error handling.

Syndicated 2009-09-13 03:52:37 (Updated 2009-09-13 03:56:07) from Lover of Ideas

A really excellent post about moving to IPv6

This really excellent post makes the analogy of upgrading to IPv6 being like moving to longer phone numbers. Not that the analogy is perfect by any means, but it is useful for illustrating some important differences in the attitudes of people towards it.

One cogent commenter mentions:

The telephone equivalent of NAT is a PBX with built-in extensions, but you're right in that no one is suggesting that PBXes will relieve the burden of upgrading the phone system at some point.

Syndicated 2009-09-11 18:58:26 from Lover of Ideas

No more autoconf for endianess detection

autoconf is annoying to work with, and I think that programs that rely excessively on it for cross platform compatibility have issues of their own. Sometimes you really have no choice though.

Fortunately I recently discovered one place where I now do have a choice where I didn't before. This little code snippet can be optimized by gcc at compile time into a constant expression. That means that gcc realizes there is only one possible result and it uses that result in place of actually running the code in the function. Here is the code snippet:

inline bool is_little_endian()
{
   const union {
      ::std::tr1::uint32_t tval;
      unsigned char tchar[4];
   } testunion = { 0x11223344ul };
   return testunion.tchar[0] == 0x44u;
}

This is guaranteed to work on C99 systems, and, as I said, gcc is capable of recognizing it as a constant expression. This also means that if you have code like this:

   if (is_little_endian()) {
      do_something();
   } else {
      do_something_else();
   }

gcc will be smart enough to see that only one branch of that if will ever be taken and optimize the other completely out of your code.

Normally you'd want to use autoconf for this so you will have a preprocessor macro that will elide the code for you. The fact gcc can optimize this well means you don't have to do that to get efficient code.

Syndicated 2009-09-10 15:27:27 from Lover of Ideas

8 Sep 2009 (updated 9 Sep 2009 at 00:11 UTC) »

IPv6 addressing oddity

I've noticed an interesting oddity in IPv6 addressing...

::ffff:n.n.n.n refers to IPv4 only hosts so that a program written for IPv6 only and running on a dual stack machine can address IPv4 only hosts. There is another class of address that is similar, but not quite the same, and I don't actually understand when it would ever be used, and that class is called "IPv4 compatible IPv6 addresses" and they are of the form ::n.n.n.n.

Interestingly the IPv6 IN6ADDR_ANY address is ::, which is equivalent to ::0.0.0.0. Fortunately, the IPv4 INADDR_ANY address is 0.0.0.0 (also known as 'this host on this network' in the 'Special Addresses' section of RFC 1700) so there doesn't seem to be any real problem.

And finally, the real problem. The IPv6 equivalent of localhost or IPv4's 127.0.0.1 is ::1, and this is equivalent to ::0.0.0.1 which makes it an 'IPv4 compatible IPv6 address'. But the IPv4 address it maps to is, according to RFC 1700, some kind of local identifier for a host on a network. That seems like an odd conflict and inconsistency to me, and I'm not really sure what it means.

Of course, I've never seen any addresses in the 0.0.0.0/8 block be used at all aside from 0.0.0.0 itself, so it's likely not a real problem. But I'm still curious.

Edit 16:36: I have the answer. According to RFC 4291 section 2.5.5.1 meaning of ::n.n.n.n addresses as 'IPv4 compatible IPv6 address' is deprecated so there is no longer any overlap in meaning between the special IPv6 addresses ::1 and :: and any IPv4 address.

Well, that was the right decision, the distinction between ::ffff:n.n.n.n addresses and ::n.n.n.n addresses was confusing and unclear anyway.

Syndicated 2009-09-08 08:11:38 (Updated 2009-09-08 23:46:30) from Lover of Ideas

Ugly C++ technique that I'm still proud of thinking of

I'm quite pleased with myself. :-) I've been participating on stackoverflow.com recently. HazyBlueDot had an interesting question in which (s)he was trying to use ::boost::function to get around a broken library interface.

In particular, the library interface allowed you to register a callback function, but it did not provide you a way of giving it a void * or something to pass back to you so you could put its call of your function back in context. HazyBlueDot was trying to use boost::function in combination with boost::bind to add in the pointer and then call his own function. The only problem is that the result boost::function object then couldn't produce an ordinary function pointer to pass to the callback.

This, of course, cannot be done in a static language like C++. It requires on the fly generation of first-class functions. C++ simply can't do that. But, there are various interesting tricks you can pull to generate functions at compile time with templates in ways that can help with this problem, even if they can fully solve it.

I'm particularly pleased with my solution, which looked something like this:

#include <boost/function.hpp>

using ::boost::function;

typedef int (*callback_t)(const char *, int);

typedef function<int(const char *, int)> MyFTWFunction;

template <MyFTWFunction *callback>
class callback_binder {
 public:
   static int callbackThunk(const char *s, int i) {
      return (*callback)(s, i);
   }
};

extern void register_callback(callback_t f);

int random_func(const char *s, int i)
{
   if (s && *s) {
      return i;
   } else {
      return -1;
   }
}

MyFTWFunction myfunc;

int main(int argc, const char *argv[])
{
   myfunc = random_func;
   register_callback(&callback_binder<&myfunc>::callbackThunk);
   return 0;
}

This basically allows you to automatically generate a 'thunk' function, a normal non-member function that can be passed to the callback, that then calls another function and adds the contents of a global variable you specify as a template parameter. It doesn't fully solve the problem, but it partially solves it. And I think in this case it will do something pretty close to what HazyBlueDot wants.

Syndicated 2009-09-05 06:21:45 from Lover of Ideas

Empathy and OTR

Empathy has been starting to make it into Linux distributions as the default IM client. I think this is a mistake at this juncture, and this bug about Empathy not supporting OTR is one of the larger reasons why.

Another reason why is that Empathy seems to be connected with several different libraries and there is no clear sense as to what functionality lives where. It appears to be something of a spaghetti mess of libraries. I mostly figured this out because of repeated calls to 'code it or shut up' in response to the bug I posted.

One of my responses was good enough that someone else felt the need to cross-post a link to it in the Launchpad bug about lack of OTR support in Empathy.

I will cross-post it here:

(In reply to comment #15)

You seem strangely interested in security... provided by (by your own words) a broken security layer? Do you really think that providing broken security, and lulling people into false sense of security is better than providing no "security" at all?

OTR's brokenness is due to the fact that it is a hacky kludge on top of existing IM protocols, not because it has any security flaws. It's inelegant and ugly, but it works.

I'm all for an elegant solution. But I don't think it should take a backseat to interoperability. I know that the various IM protocols are also mostly a bunch of ugly kludges as well. But that doesn't stop them from being implemented.

And to others. I am not a Telepathy developer... but seriously guys, flaming developers while not being ready to get yourselves on the line? If you find it useful and especially if you find it critical, do it yourself. Otherwise, feel free to keep using Pidgin until you get this critical feature, which Thilo considers broken by design.

I think there's room for other improvements before encryption, because I, and many other home users, find it unnecessary. Encryption is not important for majority of people on this world.

I am worried because Empathy appears to be getting a huge userbase and being used as the default IM client for a number of distributions without having a feature I think is incredibly important and should've been built in at the start, almost especially because most users don't really care about it.

Most people will not care about encryption. Most people also do not care about ACID database semantics. But anybody who made a database lacking the latter feature (i.e. Microsoft Access) would be roundly and justly flamed. Especially if they managed to somehow get that database into general use.

There are a whole host of features that users do not care about but are critical pieces of infrastructure. One of the things that most pleases me about Adium is that the developers understood and so many of my friends who have no clue or desire for encryption end up using it anyway because they use Adium.

If other clients provide you security, use those. Or use email+GPG for even more security. Filing a request is fine. Posting a comment supporting the request is fine. Attacking people like some of you did is not fine.

Email encryption is nearly a lost cause. But with Adium and a couple of other popular IM clients supporting OTR, widespread IM encryption was beginning to happen. I don't think activists in Iran should have to worry about which IM client their friends are using in order to avoid being snooped on. I don't think their choice of IM client should be able to be used to single them out for special treatment by their government. All new IM clients should just do the right thing out of the box.

Widespread support for good encryption is not something I care about because I am especially paranoid about my own IM conversations. It's because I care about the pernicious effects of all IM conversations being potentially public knowledge.

Someone else goes on later to suggest that Empathy support some horrible idea like TLS over XMPP. Which, in addition to being an awful idea for any number of reasons, also fails to address the issue of support for any protocol aside from XMPP.

In order for encryption to be useful in a communications system, everybody has to be able to use it whether they want it or not. It should be a first-class feature designed in from the very beginning, not tacked on as an afterthought (something that OTR in pidgin fails at) and certainly not treated as unimportant because only a few really want it.

Syndicated 2009-08-31 21:23:40 (Updated 2009-08-31 21:25:34) from Lover of Ideas

129 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!