Signals
I meant to write about this a while ago, but I forgot, and it just popped into my head for some reason.
If you’re ever using POSIX signals as a means of primitive IPC, and SIGUSR1 and SIGUSR2 aren’t enough for you, never, ever, EVER make use of SIGRTMIN and/or SIGRTMIN plus some offset. Always use SIGRTMAX and SIGRTMAX minus some offset.
Why?
(Disclaimer: this might only be a problem on Linux, but if you want your app to be portable, blah blah blah…) Depending on what C library you’re using, and what pthreads implementation you’re using, the actual numerical value of SIGRTMIN may not be the same in different applications, depending on — get this — whether or not the app links with libpthread. In my case, the pthread impl makes use of the first 3 SIGRT slots, and so when you use the SIGRTMIN macro, you actually call __libc_current_sigrtmin(), and you get a number that’s 3 higher than what you get when you use SIGRTMIN in an app that doesn’t link against libpthread.
Fortunately, SIGRTMAX (which actually expands to a call to __libc_current_sigrtmax()) seems to be a bit more stable. That is, even if SIGRTMIN gets shifted up 3 slots, SIGRTMAX is still the same.
So, the moral of the story is: I never want to see the SIGRTMIN macro ever appear in your code, unless you really know what you’re doing. Instead, use things like SIGRTMAX, SIGRTMAX-4, etc. It may just save you 4 hours of debugging.
Signals
I meant to write about this a while ago, but I forgot, and it just popped into my head for some reason.
If you're ever using POSIX signals as a means of primitive IPC, and SIGUSR1 and SIGUSR2 aren't enough for you, never, ever, EVER make use of SIGRTMIN and/or SIGRTMIN plus some offset. Always use SIGRTMAX and SIGRTMAX minus some offset.
Why?
(Disclaimer: this might only be a problem on Linux, but if you want your app to be portable, blah blah blah...) Depending on what C library you're using, and what pthreads implementation you're using, the actual numerical value of SIGRTMIN may not be the same in different applications, depending on -- get this -- whether or not the app links with libpthread. In my case, the pthread impl makes use of the first 3 SIGRT slots, and so when you use the SIGRTMIN macro, you actually call __libc_current_sigrtmin(), and you get a number that's 3 higher than what you get when you use SIGRTMIN in an app that doesn't link against libpthread.
Fortunately, SIGRTMAX (which actually expands to a call to __libc_current_sigrtmax()) seems to be a bit more stable. That is, even if SIGRTMIN gets shifted up 3 slots, SIGRTMAX is still the same.
So, the moral of the story is: I never want to see the SIGRTMIN macro ever appear in your code, unless you really know what you're doing. Instead, use things like SIGRTMAX, SIGRTMAX-4, etc. It may just save you 4 hours of debugging.
Git Snapshot Versioning?
With our SVN repository, we version SVN snapshots using the SVN revision number -- we tack "svn-r$REVISION" on the end of the normal version number. This works well, and it's easy to tell if a given snapshot is newer or older than another one.
Git doesn't have revision numbers. Commits are identified by SHA1 checksums. Since these are "random," there's no way to tell chronological order. How are other people doing git snapshot versioning? The best I've come up with is to parse git-log output to get the date and time of the last commit, and then do something like X.Y.Zgit-YYYYMMDD.HHMMSS... which is rather long and ugly. I guess it would be ok to use a 2-digit year here, though. And maybe drop the seconds bit, but I think it's decently possible to have more than one commit in the same minute. But still... long and ugly.
Any other ideas? My requirements are simple: easy to tell based on just the version string if a snapshot is older or newer than another, must be able to automatically generate this tag, and must be able to identify the exact HEAD that the snapshot was made from.
Git Snapshot Versioning?
With our SVN repository, we version SVN snapshots using the SVN revision number – we tack “svn-r$REVISION” on the end of the normal version number. This works well, and it’s easy to tell if a given snapshot is newer or older than another one.
Git doesn’t have revision numbers. Commits are identified by SHA1 checksums. Since these are “random,” there’s no way to tell chronological order. How are other people doing git snapshot versioning? The best I’ve come up with is to parse git-log output to get the date and time of the last commit, and then do something like X.Y.Zgit-YYYYMMDD.HHMMSS… which is rather long and ugly. I guess it would be ok to use a 2-digit year here, though. And maybe drop the seconds bit, but I think it’s decently possible to have more than one commit in the same minute. But still… long and ugly.
Any other ideas? My requirements are simple: easy to tell based on just the version string if a snapshot is older or newer than another, must be able to automatically generate this tag, and must be able to identify the exact HEAD that the snapshot was made from.
More Firefox 3 SSL Junk
Lately I’ve noticed a flood of Firefox 3-related posts regarding the new SSL error handling on Planet GNOME. It’s a little funny, as I was writing about this myself a little under two months ago.
Chris Blizzard posts in favor of the new arrangement, and points to an interesting post by Johnathan Nightingale explaining Mozilla’s position. Yes, agreed, Jonathan’s post is a good read, but the salient point is that the new UI is just awful from an average non-technical user’s perspective.
The extra clicks and somewhat abnormal flow (e.g. the need to click a button in the dialog to fetch the certificate) make it harder for the user to understand how to successfully add the exception. You might say that some false positives (i.e., users who fail to access a site that they really actually do want to access) is better than a user succumbing to a MITM attack, but I’m not sure I’d agree.
Equally importantly, the error messages make no distinction between the potential severity of the various SSL errors. For example, I’d say a self-signed cert on a site that you’ve never visited before is fairly low-risk. But a self-signed cert on a site that used to have a trusted cert would be a huge red flag. Domain mismatches and expired certs would fall somewhere in between. It’s hard for the average user to make an informed decision on risk/severity if they were to encounter both of these situations because the error messages and dialogs look exactly the same.
Addressing Johnathan’s main point about self-signed certs and level of security: as a highly technical/advanced user, I personally can say that, in the vast majority of instances where I encounter a self-signed cert, I really do just care about the encryption, and I don’t particularly care about the identity verification of the site that a trusted cert could offer. Now, Firefox probably shouldn’t use me as an example as a target user that needs protection, but that’s a data point nonetheless. I don’t care for things like: Bugzilla installations, my blog, accounts at sites like identi.ca, Twitter, Slashdot (they don’t offer SSL at present, but if they did…), etc.
Pretty much the only time I do care are for financial institutions. And guess what? They’ve already decided that SSL as used for identity verification is useless! Most of them (I can only think of one that I use that hasn’t) have already implemented a “security image” system wherein I pick a random image that gets shown to me every time I log in. If a site claiming to be the site I want shows me an image I don’t recognise, I’ll know that the site is a fraud. Is it perfect? Probably not. But it’s orders of magnitude better then what SSL error dialogs offer.
And I guess that’s really it: as much as I hate the phrase, I really think that the SSL error dialogs are “a solution in search of a problem.” In the cases where I care about site spoofing, the sites themselves have already implemented a better solution. In the cases where I don’t care, well… I don’t care.
More Firefox 3 SSL Junk
Lately I've noticed a flood of Firefox 3-related posts regarding the new SSL error handling on Planet GNOME. It's a little funny, as I was writing about this myself a little under two months ago.
Chris Blizzard posts in favor of the new arrangement, and points to an interesting post by Johnathan Nightingale explaining Mozilla's position. Yes, agreed, Jonathan's post is a good read, but the salient point is that the new UI is just awful from an average non-technical user's perspective.
The extra clicks and somewhat abnormal flow (e.g. the need to click a button in the dialog to fetch the certificate) make it harder for the user to understand how to successfully add the exception. You might say that some false positives (i.e., users who fail to access a site that they really actually do want to access) is better than a user succumbing to a MITM attack, but I'm not sure I'd agree.
Equally importantly, the error messages make no distinction between the potential severity of the various SSL errors. For example, I'd say a self-signed cert on a site that you've never visited before is fairly low-risk. But a self-signed cert on a site that used to have a trusted cert would be a huge red flag. Domain mismatches and expired certs would fall somewhere in between. It's hard for the average user to make an informed decision on risk/severity if they were to encounter both of these situations because the error messages and dialogs look exactly the same.
Addressing Johnathan's main point about self-signed certs and level of security: as a highly technical/advanced user, I personally can say that, in the vast majority of instances where I encounter a self-signed cert, I really do just care about the encryption, and I don't particularly care about the identity verification of the site that a trusted cert could offer. Now, Firefox probably shouldn't use me as an example as a target user that needs protection, but that's a data point nonetheless. I don't care for things like: Bugzilla installations, my blog, accounts at sites like identi.ca, Twitter, Slashdot (they don't offer SSL at present, but if they did...), etc.
Pretty much the only time I do care are for financial institutions. And guess what? They've already decided that SSL as used for identity verification is useless! Most of them (I can only think of one that I use that hasn't) have already implemented a "security image" system wherein I pick a random image that gets shown to me every time I log in. If a site claiming to be the site I want shows me an image I don't recognise, I'll know that the site is a fraud. Is it perfect? Probably not. But it's orders of magnitude better then what SSL error dialogs offer.
And I guess that's really it: as much as I hate the phrase, I really think that the SSL error dialogs are "a solution in search of a problem." In the cases where I care about site spoofing, the sites themselves have already implemented a better solution. In the cases where I don't care, well... I don't care.
Microblogging
I’ve had a Twitter account for a while, though I never really made much use of it. I recently signed up for an Identi.ca account as well. I was pointed to this video which tries to show how Identi.ca isn’t just another Twitter. My understanding is Identi.ca is mainly an interop and OSS play, which certainly appeals to me. Identi.ca also lets you use your OpenID to log in and set up an account, which is cool (despite OpenID’s inherent phishing problems that its designers have chosen to ignore).
But, as we all know, the value of such a tool mainly lies in network effects. So, who has an Identi.ca or Twitter account? Feel free to subscribe to my feed or drop me a note so I can find you.
Since I don’t write (publicly) in this blog so much anymore, perhaps microblogging will be my next public “thing.”
Microblogging
I've had a Twitter account for a while, though I never really made much use of it. I recently signed up for an Identi.ca account as well. I was pointed to this video which tries to show how Identi.ca isn't just another Twitter. My understanding is Identi.ca is mainly an interop and OSS play, which certainly appeals to me. Identi.ca also lets you use your OpenID to log in and set up an account, which is cool (despite OpenID's inherent phishing problems that its designers have chosen to ignore).
But, as we all know, the value of such a tool mainly lies in network effects. So, who has an Identi.ca or Twitter account? Feel free to subscribe to my feed or drop me a note so I can find you.
Since I don't write (publicly) in this blog so much anymore, perhaps microblogging will be my next public "thing."
My Birthday is Awesome
The 4th of July is the opposite of other holidays like Christmas or Halloween where there's a lot expected of you. You're expected to buy presents, or you're expected to have a snazzy costume. The 4th of July only asks that you show up and get totally relaxed. It's an [sic] big eating holiday, but unlike Thanksgiving, the most complicated cooking involved is placing a burger onto the grill and then taking it off the grill.
(from SIMYP)
Social Fallacies
I ran across this list of Geek Social Fallacies yesterday. It's a pretty old list; I'm surprised this is the first time I've seen it. It's pretty interesting, and, I'd wager, pretty accurate. I've seen these everywhere to varying degrees in the OSS world. Personally I tend to suffer a lot from #3 (though I usually recognise this one and realise that most, if not all, of my friends aren't like me in this regard, so this tends to not be that bad at all), and quite a lot of #5 (when I'm on the receiving end of a lack of an invitation, it can hit me pretty hard).
I see a lot of #1 among OSS contributors. Many OSS people seem to believe that everyone's opinion has equal value, or at least should be considered with equal weight. I often see "poisonous people" who just like to rant, or don't understand a particular community. Sometimes they're actively malicious, and sometimes they're genuinely trying to help, but don't understand what's going on to actually be useful. Often these people will never get it, and in these cases I greatly advocate cutting them off and kicking them out. Unfortunately, a lot of people see this as rude, or anti-community, or some bullshit like that. Sorry, but the real world just doesn't work that way: some people just don't, and can't, belong.
As for #4, it's often a shame. I'm fully aware that I have different groups of friends for a reason, and that in most cases, my different friends wouldn't really get along. Not that they'd be actively hostile, just that they wouldn't find much in common and would probably be bored with each other during extended interaction. It's pretty rare that I introduce friends and they actually hit it off.
2 is actually pretty rare in my experience. Personally, I tend to believe that my close friends do accept me as I am, and actually because of that, they're the ones most likely to criticise me when I'm acting like a dick. And I (usually) welcome that.
Anyhow... pretty interesting.