Older blog entries for Omnifarious (starting at number 129)

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

30 Aug 2009 (updated 30 Aug 2009 at 23:09 UTC) »

Is this really faster?

This:

unsigned int clipdigit(unsigned int * const v)
{
   unsigned int digit = (*v) % 10;
   (*v) /= 10;
   return digit;
}
is turned into this:
.globl clipdigit
	.type	clipdigit, @function
clipdigit:
.LFB11:
	.cfi_startproc
	movl	(%rdi), %ecx
	movl	$-858993459, %edx
	movl	%ecx, %eax
	mull	%edx
	shrl	$3, %edx
	leal	0(,%rdx,8), %eax
	movl	%edx, (%rdi)
	leal	(%rax,%rdx,2), %edx
	movl	%ecx, %eax
	subl	%edx, %eax
	ret
	.cfi_endproc
.LFE11:
	.size	clipdigit, .-clipdigit

As a small hint/bit of explanation, 232 - 858993459 = 3435973837 = 235 / 10 + 2.

Is mull really that much faster than divl on x86_64 machines?

I was expecting to get code more like this rather straightforward bit:

.globl clipdigit
	.type	clipdigit, @function
clipdigit:
.LFB11:
	.cfi_startproc
	movl	(%rdi), %eax
        movl    $10, %ecx
        xorl    %edx, %edx
        divl    %ecx
        movl    %eax, (%rdi)
        movl    %edx, %eax
	ret
	.cfi_endproc
.LFE11:
	.size	clipdigit, .-clipdigit


It turns out in testing that the second clip of code is much, much slower than the first clip. The strange mull method is about 5 times faster than the straightforward divl method. Wow, divl seems really broken if it's that slow.

Syndicated 2009-08-30 20:38:53 (Updated 2009-08-30 22:39:02) from Lover of Ideas

C++ on the iPhone

While I do not recommend that anybody develop anything for the iPhone, I was recently investigating something about it.

I would like to repeat that I do not recommend that anybody develop anything because Apple's policies make it questionable as to whether or not your app will ever make it to the app store at all. They have no compunctions about refusing apps for the most bizarre of reasons, and even worse, refusing apps because either Apple or AT&T perceives them as somehow competing.

If you want to develop for a mobile phone platform, go for the Android. That is a clear and open market.

That being said, I did have reason to investigate C++ on the iPhone recently, and I came across these 3 well-written articles by someone who's tried to develop C++ on several different mobile phone environments. I would like to point to them here because other people looking for this information should be able to find it easily, and so I can find it easily.

  • C++ on iPhone: Part 1 - in which its discovered that yes, constructors for global variables are indeed run before main starts and their destructors are called after main ends.
  • C++ on iPhone: Part 1a - Yeah, yeah, the last one didn't seem at all iPhone specific, but really I did run it on an iPhone and it worked just like it ought to.
  • C++ on iPhone: Part 2, Exceptions - Why yes, exceptions do indeed work, and there's even some hints that there's been an attempt at integration between Objective-(C/C++) 2.0 exceptions and C++ ones.
  • C++ on iPhone: Part 3, Run Time Type Identification - Yep, this works too.
  • Of BOOL and YES - BOOL is an evil Objective-C type that's really a typedef and a holdover from the days when C didn't have a bool type. Don't forget that there are many values that mean YES besides YES, so compare against NO if you have to compare. (IMHO, you should just always assign to a real bool type as the iPhone C compiler is C99 compliant and that does have bool).

So yes, it appears the iPhone does C++ just fine. That guy was promising to write more on how Objective-(C/C++) and C++ mixed. But I don't think he ever got around to it.

Syndicated 2009-08-22 12:10:58 (Updated 2009-08-22 12:20:38) from Lover of Ideas

21 Jul 2009 (updated 22 Jul 2009 at 01:11 UTC) »

Amazon randomly burns people's copies of 1984

The publisher of several books by George Orwell decided that they didn't like the fact that they'd published them electronically. Many people had bought these books for their Kindle. Mysteriously, these books completely disappeared from people's Kindle book readers.

In my humble opinion, people who bought a Kindle deserve exactly what they got, and I hope Amazon does it again. If you buy into DRM in any way you are asking for stuff like this to happen to you. The reasonable response is not to complain bitterly about how unfair it is, but to not buy DRM enabled products.

People seem in a terrible rush to trade away rights that are essential in the rush to convenience. They spare little thought for what they're doing and then act surprised at the ultimate result.

At the recent Convergence I was on a panel about copyright. People there persisted in calling copyright a 'property right' and referred to the vast network of weird and wonderful rights that are patents, trademarks and copyrights as 'intellectual property'. I object strongly to the conflation of trademark, patent and copyright into 'intellectual property'. The rules around each are very non-property-like and very different from each other.

And Techdirt comes to the rescue again with an article about how in many ways copyright is very much not a property right.

Syndicated 2009-07-21 22:25:18 (Updated 2009-07-21 23:37:23) from Lover of Ideas

20 Jul 2009 (updated 21 Jul 2009 at 06:09 UTC) »

Another great Linux game

I haven't played it yet, but I would like to note that Frictional Games has released Penumbra for Linux.

Blog of Helios wrote a nice blog entry detailing why this is such a great game. Unlike World of Goo, I'm not sure how well it will work on older hardware.

It's really nice to start seeing publishers of really good games start supporting Linux. The smaller publishers in the games industry tend to make the most interesting games, and it's the smaller publishers that have been doing Linux ports. Even though the larger publishers make less interesting games, their games tend to be more popular. I hope that the success smaller publishers have with porting leads larger publishers to start doing the same thing.

Games are an exception to my rule about using all Open Source if I can help it.

This game is a bit tricky to install on Linux, mostly because of library dependencies, especially on a 64-bit system. Frictional could use some install advice from the nearly trivial to install World of Goo game.

Syndicated 2009-07-20 19:12:53 (Updated 2009-07-21 05:14:28) from Lover of Ideas

Amazingly fun commercial game for Linux!

It's World of Goo. It's like a mad cross between Fantastic Contraption and Lemmings.

The best part (in my world anyway :-) is that the game is available for Linux. I wish more game companies would start doing this. It isn't that hard, and there is a market for it. Nearly as much of a market as for Mac games.

The game has gotten some fantastic reviews. It is light-hearted and bizarre, and the physics simulation based puzzles are highly entertaining. Other comparisons that come to mind are the work of Tim Burton and the video game Worms, more for artistic style than anything about how gameplay actually works.

Syndicated 2009-07-17 22:51:57 (Updated 2009-07-17 23:00:19) from Lover of Ideas

27 Jun 2009 (updated 27 Jun 2009 at 18:08 UTC) »

Programmer's block

I've been working on coming up with a nice C++ (or, actually, C++0x) interface to Skein hash function.

Skein has an interesting tree mode in which it's possible to parallelize the hash function calculation to a significant degree. I wanted to write a general interface for this so I could make a command line utility that used it to test it against sha256sum command.

Applying a tree hash to an existing file is a no-brainer. But I wanted to be able to handle much more general cases in which the leaf data may not be available on a random-access basis. In particular if the file is coming in on stdin or something similar.

I was having difficulty coming up with a general extensible interface for this. Partly the interface for the system for handling leaf data needed a way to allocate chunks of leaf data to work on, and then release them. This would allow for a sliding window type approach to fetching leaf data.

My biggest and most recent breakthrough was realizing that the leaf data objects were like ::std::auto_ptr objects. I didn't want to force heap use, so I needed the data about a leaf to be copyable. But I didn't want to have to have any kind of silly reference counts or anything like that. So that meant I needed it to be moveable, not copyable. Just like auto_ptr. But auto_ptr is a klduge in C++. In C++0x there is a very nice concept called rvalue references that let you implement move semantics very cleanly.

It took me awhile to realize I wanted move semantics. I kept on beating on the interface and coming up with usage scenarios that were just awkward and broken. Once I figured it out, things went a lot easier.

Here is a link to what I finally came up with: skeintreepp.hpp.

Syndicated 2009-06-27 07:22:29 (Updated 2009-06-27 17:42:23) from Lover of Ideas

14 Jun 2009 (updated 14 Jun 2009 at 10:18 UTC) »

Number puzzle

Many years ago I was presented with an interesting puzzle. I did not solve it. I had to be told the answer. It is a very simple answer, but it isn't dumb. Figuring it out requires a significant leap of lateral thinking.

I figured I'd put it here for the amusement of others. Comments will be screened. I will eventually reveal the correct answer, but it may be a few months. :-) And now for the puzzle itself:

What is the next number in this sequence?

  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 20
  • 22
  • 24
  • 31
  • 100
  • 121

Syndicated 2009-06-14 09:08:24 (Updated 2009-06-14 09:09:35) from Lover of Ideas

What I've been up to for the past few days

Well, actually, a whole lot of stuff, including spending some time with [info]klicrai and someone who tends to go by Crymerci online, but doesn't have an active LJ.

But, the topic of this LJ entry is the work I've been doing on creating a nice C++ interface for Skein, Bruce Schneier and friends entry into the NIST SHA-3 competition.

Anyway, I'm basing my work on the code in their NIST submission. And, as I said before, it's a nice C++ wrapper for Skein that attempts to give access to all of Skein's nifty features that are in excess of the NIST requirements. It's a hash function, it's a PRNG, it's a MAC algorithm! No, it's Skein!

One kind of gets the impression that Bruce and company are miffed by the fact that Rijndael was chosen over Twofish for the AES competition. And their response was to create a new algorithm that was faster, probably more secure, inordinately flexible and impossible to level the "it's too complicated to analyze effectively" criticism against. That criticism was one of the reasons Twofish wasn't selected in the AES competition.

Syndicated 2009-05-24 01:36:58 from Lover of Ideas

Statistical patterns in primes

There is an interesting new result showing that the distribution of prime numbers obeys a modified version of Benford's Law. The result also shows that another sequence who's distribution is somehow fundamentally related to the distribution of primes, the 0s of the Reimann zeta function.

It is my feeling that results like this do not strongly affect the usefulness of prime number based cryptography algorithms like RSA. But this is just a guess on my part. Does anybody have a more definitive answer?

Syndicated 2009-05-15 01:18:23 from Lover of Ideas

120 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!