kai_mactane: (Default)

I see that I never bothered announcing the v0.61 release. That was a minor bug-fix, resolving an issue where Hummingbird would fail if the XML cache file was empty.

The latest release is one that allows multiple versions of Hummingbird to run on the same machine without conflict, as long as they’re using different Twitter usernames.

In addition, I’ve changed the destination of auto-hashtag links. Since the hashtags.org service is often a bit flaky, or simply returns useless null results, I’ve switched to using Twitter’s own internal search service.

Downloads are available from the Hummingbird project page, or using these links:

hummingbird-0.65.tar.gz
hummingbird-0.65.zip

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)
First, a note about pingbacks: Pingbacks simply let you know when another LJ user posts an entry (on LJ) that links to one of yours. It does this by adding a screened comment to your entry, which also means you get your usual comment notification. If you take no action, nobody else sees a thing. (You could unscreen the comment, if you want.)

I have no problem with this.

Then there's that Facebook crosspost feature. That's a little more dodgy. Just to make clear what it does and doesn't do (based on Livejournal's FAQ entry called "How do I update my Facebook or Twitter when I post to LiveJournal?"):
  • If you set it to crosspost your own entries by default (or automatically), it will do just that — but only for public entries. As I understand it, it will not send your friends-locked posts to other services.
  • If you set it to crosspost your comments by default (or automatically), it will crosspost every comment you write... even if that comment is on someone else's journal. Even if that comment is on someone else's friends-locked post.

Note that I'm taking Livejournal's word on this, perforce, because I deleted my Facebook account a few months ago. (Yes, because of privacy concerns. Funny, that.)

A public comment on the announcement about this sums up the problem pretty well: “Say, for example, you complain about your manager at work under f-lock. Someone can then reply with, "Man, your manager sounds like a bitch", and crosspost that to their Facebook. The possibility for badness is epic.” (I see no problem in linking to or quoting a public post. The main substance of the objections to this is that it tends to publicize information that was intended to be friends-locked.)

Some people have pointed out that a person who can see one of your protected entries can always copy-paste the whole thing. True enough, and that's not even really a technological problem; it's a social problem. If you tell a friend a secret verbally, they can always violate your confidence and spread the "secret" far and wide. No technology can guard against people deliberately breaking trust with you.

However, this setting would automatically and habitually publish one's comments to Facebook, without the person having to take any deliberate action. This makes it very easy to forget about. And totally aside from the way people can leak information by posting things that make it obvious what they're responding to, there are also the people who sometimes quote part of the post they're responding to.

In general, this is a good thing. Heck, I do it myself whenever I feel it's warranted. But until now, we've all done so with the knowledge and understanding that what we copied and quoted was staying on the same page, with the same read permissions.

That's no longer true. Now, if Joe or Jane responds to someone's friends-locked post, their comment can be automatically crossposted to Facebook without my even thinking about it, based on a checkbox they ticked at some point in the past.

Or, more apropos to my life: If I write a locked post, and my friend Stan writes a response that quotes some of my text (because it's the sensible thing to do in that context), Stan can accidentally export my words out to a service that I've deliberately severed all ties with. Even if he'd never consciously, deliberately do so.

That's what bugs so many people about this. That what bugs me about it, too.

My policy has always been that if I post something publicly, with no friends-lock, that means it's intended to be public. Link to it freely, no permission needed. I see no reason to change that policy, and you'll note that I've made this post public.

But to my friends who comment on my journal: Please, don't crosspost my locked stuff to other services. And don't crosspost text that makes it obvious what I must have written, either. I locked it for a reason.
kai_mactane: (Default)

If you haven’t been getting as much email as usual this past week, the culprit may be SpamAssassin. It turns out that SpamAssassin 3.2.5 (the current version, released in June of 2008) has a Year 2010 Bug.

The problem lies in the core configuration file 72_active.cf, which contains a wide variety of “currently active” rules. On line 543, it says:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

For those who don’t read regular expressions, this rule will match any Date: header that contains a string like 201x, 202x, 203x, etc., where “x” could be replaced by any digit. So, back in 2008, this rule would catch email that claimed to hail from the year 2010 or later. (Well, up to 2099.)

Starting on the morning of last Friday, this rule started triggering on pretty much all mail that hadn’t been delayed, thus adding 3.384 points to every piece of incoming email. Naturally, this could easily push mail over the threshold from “not spam” into “spam” when it doesn’t belong there.

If you’ve been expecting some mail that hasn’t arrived, and your mail host uses SpamAssassin, you might want to check your spam folder.

According to a note on the SpamAssassin project’s main page, you can easily correct this problem in either of two ways:

  1. If your system is configured to use sa-update, run it now.
  2. Remove the FH_DATE_PAST_20XX rule altogether by putting “score FH_DATE_PAST_20XX 0″ at the end of your local.cf file.

Alternatively, if you’re the mail administrator, and you don’t mind setting up a Year 2020 Bug for yourself, you could always change the part that says Date =~ /20[1-9][0-9]/ so that it says Date =~ /20[2-9][0-9]/ instead. After all, stuff that claims to be from years in the future (or past) is likely to be something you don’t feel like reading. But if you do this, I strongly urge you to find some way to send yourself an alert around December of 2019, warning yourself that you need to fix that problem. (And that may be easier said than done.)

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

Yesterday, a wonderful person who goes by the handle of pzil on the Palm Prē forums gave me a solution to my “You are signed out, there is no escape” woes. You can read pzil’s solution as posted on the Palm forum, but just in case, I’m also reproducing the meat of it here, in case it helps anyone else.

Again, I take absolutely no credit for this one; all credit goes to pzil.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

I’ve always questioned the wisdom of building a startup company based around someone else’s platform, like Facebook games or Gmail inbox add-ons. You’re totally at the mercy of the other company. (Many people have found out how silly it was to go up against Microsoft or Apple in just the same way.)

And yet, here I am with Hummingbird, which is totally dependent on Twitter’s bandwidth. (In my own defense, I can only point out that: a) I wrote it because I needed the functionality; and b) I’m not building a money-making company around Hummingbird. I’m just giving it away.)

In the past couple of weeks, I’ve noticed that Twitter can sometimes take an astonishingly long time to provide an update. Hummingbird works by requesting URLs like http://twitter.com/statuses/user_timeline/kmactane.xml?count=25, and (up until now) it worked on the assumption that Twitter couldn’t possibly take longer than 10 or 15 seconds to respond to such a request.

That turns out not to be the case.

In fact, my recent tests have shown that Twitter can sometimes take over 5 full minutes to finish responding to such a request. This is a problem, because the default installation of Hummingbird tries to update its cached data once every 5 minutes. And since I assumed the request would be fulfilled in, at most, 10% of that time, I didn’t bother building in any concurrency checking.

I’ve just completely reorganized most of Hummingbird’s architecture. The interface that a blog owner sees (in the sense of the configuration variables in hummingbird.php, and the calling syntax for blog pages and cron jobs) is still the same. However, all of the code for retrieving data from Twitter has been spun off into a new hummingbird-cache.php file, which can be launched into the background by the rest of Hummingbird, so that it can patiently take as long as it needs to in order to update the blog’s tweets cache.

The Major Change This Causes

In Hummingbird’s previous incarnations, it would freshen an out-of-date cache before displaying it. The assumption was that every once in a while, someone might have to wait a few more seconds before seeing your blog page. However, everyone would always see an up-to-date record of your tweets. (Where “up-to-date” means “no more than 5 minutes old, absolute tops”. If you tweet so relentlessly that that’s a problem, you probably don’t have enough time to keep up your blog…)

Now that we know that Twitter can take over 5 minutes to give you the data needed to freshen your tweets cache, that design is not acceptable. Instead, Hummingbird is now committed to showing the contents of your tweets cache as quickly as possible, and only then does it fork the cache-update process into the background.

This means that, if you’re not using cron or some other automatic job-scheduling facility to run Hummingbird every 5 minutes, visitors who arrive at your blog after a period of inactivity will see an out-of-date, stale listing of your tweets.

If you have a cron job set to keep Hummingbird fresh, you’ll be fine. (A page view will also trigger an update, so if you get so much traffic that there’s never a 5-minute period during which your page doesn’t get hit, you’ll also be fine.)

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

Last week, I wrote that I’d been working on a script to easily install homebrew apps on the Palm Prē. It now looks like there are much better ways to handle such things — I’ve become quite a fan of fileCoaster, myself, and of course webOSQuickInstall is a wonderful piece of work, as well. But just in case anyone might find this shell script useful, I’ll release it for general use.

Assumptions

  1. You have a web-accessible server where you put your development .ipk files.
  2. You can ssh into your Prē.

Download

You can download the script at http://kai.mactane.org/software/libraries/download/homebrew.sh.

Installation

Just drop the shell script into your home directory and make it executable. If you want to be able to use the “my” argument, you’ll also need to edit the three configuration variables at the beginning: MY_HOSTNAME, STDPATH, and STDVERSION.

Usage

For most purposes, you’ll just want to install your own package that you’ve been working on. Assuming you’ve set the config variables correctly, you can just type ./homebrew.sh my appname, where the appname is the base name of your package.

If you’re installing multiple .ipks and you don’t need to restart the GUI manager for each one, you can use the “skip” command on all but the last:

./homebrew.sh skip my foo

./homebrew.sh skip my bar

./homebrew.sh skip my baz

./homebrew.sh my quux

You can also supply a complete URL: ./homebrew.sh http://forums.precentral.net/spe_attachment/download-23971-com.palm.net.precoder.fcoaster_1.0.2_all.ipk will download and install fileCoaster, so you won’t have to mess with my script any more.

What It Does

It automates the process of installing homebrew apps with a rooted Prē, as described on the webOS Internals wiki. Basically, it remounts the root partition in read-write mode, wgets your .ipk file, installs it, does the “Good Housekeeping” backup, remounts the root partition in read-only mode again, and then restarts the GUI manager.

Originally published at Coyote Tracks. You can comment here or there.

Profile

kai_mactane: (Default)
kai_mactane

July 2011

S M T W T F S
     12
3456789
101112 13141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 23rd, 2017 08:43 pm
Powered by Dreamwidth Studios