Update / Solution for broken Android calendar syncing
In my last post, I described how Android's calendar syncing was broken for me. I noticed that my calendar on my phone was out of date, and when I manually refreshed, I'd get a force-close error.
After downloading the Android source, figuring out how to build, and playing with it on the emulator and my device for some time, I have figured out what the problem is, and have a work-around for it. Essentially some repeated events can have a start-date Android is unhappy with (I believe it's due to a start time of UTC 0). This causes an Android core library to throw an TimeFormatException which is never properly handled, preempting syncing. This is a pretty big bug -- that exception should be caught by Google's common calendar code, but the exception is ignored. (This is because of the misuse of unchecked exceptions --- android.util.TimeFormatException inherits from RuntimeException for no good reason at all that I can see. Checked exceptions are one of the best features of Java, and inheriting from RuntimeException for things that should be handled is a really bad idea, IMO.).
Here is the text of the item that was breaking my calendar syncing:
<gd:recurrence>DTSTART;TZID=GMT+05:30:20120104T210000 DTEND;TZID=GMT+05:30:20120104T220000 RRULE:FREQ=WEEKLY;INTERVAL=1;UNTIL=20121231T182959Z BEGIN:VTIMEZONE TZID:GMT+05:30 X-LIC-LOCATION:GMT+05:30 BEGIN:STANDARD TZOFFSETFROM:+0530 TZOFFSETTO:+0530 TZNAME:IST DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE </gd:recurrence>
This was in the private url for my feed. You can see yours here:
https://www.google.com/calendar/feeds/USER_NAME%40gmail.com/private/full. I think this event was added by Outlook somehow, but I'm not really sure. The web UI and other clients have no problem dealing with this event, but Android's date parser is unhappy with it. If you're seeing repeated calendar syncing crashes, go to the above url, replace USER_NAME with your user id, and see if you have something similar to this string. If so, deleting that event ought to fix syncing.
How Google should fix this
If someone on Android or Calendar is reading this, there are two ways this should be fixed. Please do both of them!
- Fix Android to handle these errors gracefully. I patched the provider code to fix this bug. Someone should fix this, and include it in the next ICS update. Here's the diff:
vijayp@thecoon:/mnt/largelinux/bigfiles/as2/frameworks/opt/calendar/src/com/android/calendarcommon$ git diff -w
diff --git a/src/com/android/calendarcommon/RecurrenceSet.java b/src/com/android/calendarcommon/RecurrenceSet.java
index 3b91a1d..8e1117e 100644
--- a/src/com/android/calendarcommon/RecurrenceSet.java
+++ b/src/com/android/calendarcommon/RecurrenceSet.java
@@ -178,6 +178,7 @@ public class RecurrenceSet {
*/
public static boolean populateContentValues(ICalendar.Component component,
ContentValues values) {
+ try {
ICalendar.Property dtstartProperty =
component.getFirstProperty("DTSTART");
String dtstart = dtstartProperty.getValue();
@@ -233,6 +234,11 @@ public class RecurrenceSet {
values.put(CalendarContract.Events.DURATION, duration);
values.put(CalendarContract.Events.ALL_DAY, allDay ? 1 : 0);
return true;
+ } catch (TimeFormatException e) {
+ // This happens when the data is out of range.
+ Log.i(TAG, "BAD data: " + component.toString());
+ return false;
+ }
}
- Patch the calendar FE server to remove things that break android. Fixing Android is the correct solution because it's unclear that the data it is passing are actually bad. But since the Calendar Frontend can be fixed in a few days, and it might take months (or years!) to get carriers to agree to roll out an Android update, it's best to just patch the Calendar FE to filter out data that might cause Android to crash. It can even be enabled based on the useragent.
Anyway, I really hope someone at Google reads and fixes this. I spent a lot of unnecessary time tracking this down!
Android calendar syncing is broken for me!
For the past couple of weeks, (shortly after my nexus s upgraded itself to ICS), the calendar on my phone has not been syncing with Google. This has required me to use the calendar website on my phone, which is not a pleasant experience at all. So today, I hooked my phone up to my computer and decided to do some debugging. Using adb logcat, I found this stack trace:
E/AndroidRuntime(15353): FATAL EXCEPTION: SyncAdapterThread-2 E/AndroidRuntime(15353): android.util.TimeFormatException: Parse error at pos=2 E/AndroidRuntime(15353): at android.text.format.Time.nativeParse(Native Method) E/AndroidRuntime(15353): at android.text.format.Time.parse(Time.java:440) E/AndroidRuntime(15353): at com.android.calendarcommon.RecurrenceSet.populateContentValues(RecurrenceSet.java:189) E/AndroidRuntime(15353): at com.google.android.syncadapters.calendar.EventHandler.entryToContentValues(EventHandler.java:1138) E/AndroidRuntime(15353): at com.google.android.syncadapters.calendar.EventHandler.applyEntryToEntity(EventHandler.java:616) E/AndroidRuntime(15353): at com.google.android.syncadapters.calendar.CalendarSyncAdapter.getServerDiffsImpl(CalendarSyncAdapter.java:2223) E/AndroidRuntime(15353): at com.google.android.syncadapters.calendar.CalendarSyncAdapter.getServerDiffsForFeed(CalendarSyncAdapter.java:1954) E/AndroidRuntime(15353): at com.google.android.syncadapters.calendar.CalendarSyncAdapter.getServerDiffsOrig(CalendarSyncAdapter.java:945) E/AndroidRuntime(15353): at com.google.android.syncadapters.calendar.CalendarSyncAdapter.innerPerformSync(CalendarSyncAdapter.java:417) E/AndroidRuntime(15353): at com.google.android.syncadapters.calendar.CalendarSyncAdapter.onPerformLoggedSync(CalendarSyncAdapter.java:302) E/AndroidRuntime(15353): at com.google.android.common.LoggingThreadedSyncAdapter.onPerformSync(LoggingThreadedSyncAdapter.java:33) E/AndroidRuntime(15353): at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:247) W/ActivityManager( 153): Force finishing activity com.google.android.calendar/com.android.calendar.AllInOneActivity V/CalendarSyncAdapter(15353): GDataFeedFetcher thread ended: mForcedClosed is true
Thanks to Evan I was able to clone the git repo for the Calendar app (https://android.googlesource.com/platform/packages/apps/Calendar.git) , and spent some time today trying to track down this bug.
Unfortunately, the buggy code is in calendarcommon, which isn't included as part of the git file, and is actually nearly impossible to find. At any rate, with some more digging, the closest I could get is the code here
http://git.insignal.co.kr/?p=mirror/aosp/platform/frameworks/opt/calendar.git;a=blob;f=src/com/android/calendarcommon/RecurrenceSet.java
I think there needs to be a try/except block for that whole method (around line 189) that returns false if an exception is thrown. For some reason that TimeFormatException is derived from RuntimeError (!!). The common code doesn't seem to be installed as part of the calendar app. From quickly looking at the code, It appears as if it is installed as part of the os and registers itself as the handler for calendar uris.
So if I wanted to fix this myself, I'm wonder whether I would have to fork the code above, and install it as a new handler, then somehow hide the one with the OS? I have to think about this a bit more. The other problem is that since this is a common library, many other calendar apps might suffer from the same exception when they attempt to sync.
In the meantime, I'm going to try to figure out what event is causing this error (not easy since there are no logs that can help me) and/or think of buying an iPhone.
If you know anyone on Android who could help with this, please let me know.
Edit:
I'm downloading the entire android source code, and I think I'm going to try to re-build a patched version of the common code, uninstall the existing common code, and push the new one over it. I'll update this post with progress ...
Partychat — migrating from Google App Engine to EC2
I’m Vijay Pandurangan, and I’ve been working with some other super talented folks to help maintain the partychat code, and help pay for its services. Because of the latter, I was especially motivated to keep Partychat's costs under control!
Recently, Google App Engine made some substantial pricing changes. This affected a lot of people, but especially partychat, a service with over 13k one-day active users.
In this blog post (and a couple of more to follow), I’ll describe various aspects of the pricing change and our ensuing migration from App Engine to Amazon’s EC2, the impact on users, including cost structures and calculations.
For those of you who don’t have the time to read everything, here’s the
tl;dr version:
- Google’s new pricing was totally out of line; we were able to re-create similar service at about 5% of the cost of running the service on App Engine.
- Google’s policy has resulted in higher costs for them (XMPP messages used to be entirely within their network, but now have to be sent to and from EC2), and reduced their revenue (we, and others will likely shun App Engine)
- App Engine requires a very different design paradigm from “normal” system design.
- Some App Engine modules lock you in to the platform. We had to make all our users transition from channel@partychapp.appspotchat.com to channel@im.partych.at because Google does not allow us to point domain names elsewhere.
- You can operate things on EC2 substantially more cheaply than App Engine if you design correctly.
- I strongly recommend against running anything more complicated than a toy app on App Engine; if Google decides to arbitrarily change its pricing or change the services they offer, you’ll be screwed. There is really no easy migration path. Random pricing changes coupled with lack of polish in appscale means that any solution differing even slightly from the ordinary is “stuck” on appengine.
- Transitioning a running app is pretty hard, especially when it’s an open source project done on spare time.
- By (partially) transitioning off of app engine, we’ve actually reduced our cost from the pre-increase regime and can deliver roughly equivalent capacity for the same cost:
Before: $2/day.
With price increase: ~$20/day.
On EC2(no prepay)/App engine hybrid: $1/day.
On EC2(annual prepay)/App engine hybrid: $0.80/day.
At this point, residual app engine charges still amount to approximately $0.50/day.
On EC2(annual prepay)/App engine hybrid using more memcache: $0.60/day.
Background:
Partychat is a group chat service. By going to a web site, or sending an IM, users create virtual chat rooms. All messages sent to that chat room alias are then broadcast to all other users in that channel. Here is an example of two channels with two sending users.
This is what happens from the perspective of our app:
Google’s service calls an HTTP POST for every inbound message to a channel, and outbound messages are sent via API calls.
Cost estimates:
Before Google’s pricing changes, our daily cost to process messages was about $2/day. Before the new pricing went into effect, I used some anonymous logging information to forecast how much the service would cost to operate in the new pricing regime.
As you can see from the graph, even limiting the maximum room size to 200 people (which would be a major disruption to our services), would have cost us well over $10/day, which is really unacceptable.
Migration:
Since this was an open-source project I decided to take the simplest approach possible to make this migration. I’d create an XMPP server on EC2 that would simply do all the sending and receiving of XMPP messages instead of App Engine.
Note that as a result of their policy, Google makes less money AND has higher costs! (All XMPP traffic now gets routed through EC2, which is taking up bandwidth on their peering links)
Our App Engine app still does almost all of the processing of messages (including deciding who gets sent which messages), but does not do the actual fanout (i.e. creating n identical messages for a broadcast message). That is handled in the proxy.
XMPP Server:
In order to run an XMPP proxy, we need to deploy an XMPP server with the ability to federate to other servers, and code that interfaces with that server and receives and sends messages.
There are a bunch of XMPP servers out there, but the overall consensus is that ejabberd, a server written in Erlang (!) is the best and most stable. It’s proven to be extremely stable, and efficient. The big issue is that configuration is really difficult and not very well documented. A couple of important points that took forever to debug:
- ejabberd has a default traffic shaping policy. Traffic shaping restricts in-bound and outbound network traffic to according to a policy. Traffic that exceeds the limits are buffered until the buffer is full, then dropped. Partychat’s message load can often be substantially higher than the default policy’s limit for sustained periods, resulting in randomly-dropped messages.
- if multiple servers associate with one component (more on this in the next section) ejabberd will round robin messages between the connections. This means that your servers have to run on roughly equal machines.
Proxy code:
XMPP supports two connection types, Client and Component. A client connection is what your chat client uses to connect to a server. It requires one connection per user, and the server remembers all the important state (who you are friends with, etc..). This is by far the simplest solution for writing something like partychat, but there are a few problems. It requires the server to keep track of some state that we don’t care about (Are the users online? What are their status messages? etc..) which adds load to the server’s database. This can be solved by increasing database capacity, but this is wasteful since these data are not used. More importantly, using client connections will require one TCP connection per user (see the image below). This means that for our service, with ~ 50k users, our server will need to handle 50k TCP connections. This is already a really large number, and will not scale that well.
The alternative (which I selected) was to use a component interface (see above image), which essentially gives you the raw XML stream for any subdomain. Your code is then responsible for maintaining all state, responding to presence and subscription requests.
Initially we used SleekXMPP, a python library to manage component connections. The state was stored in RAM and then periodically serialized and written out to disk. Since XMPP has provisions for servers to rebuild their state in case of data loss without human involvement, losing state is not catastrophic, though it results in substantially higher load on the system while redundant subscription messages are dispatched and processed. The state that we store currently contains:
user := string (email)
channel:= string (name of channel, utf-8)
inbound_state := {UNKNOWN, PENDING, REJECTED, OK}
outbound_state:= {UNKNOWN, PENDING, REJECTED, OK}
last_outbound_request := timestamp
The last outbound request timestamp is required to prevent subscription loops in case sequence ids are not supported (the spec details why this is important.)
Each inbound message results in an https request to the app engine server. The server responds with JSON containing a message that is to be sent, a list of all recipients, and the channel from which it is to be sent.
The python library was OK, but did not really operate too well at our scale. Profiling showed that much time was spent copying data around. The server periodically crashed or hung, resulting in dropped messages and instability. The inefficiency required us to use a medium instance ($0.17/hour) to serve traffic, which put us at about $4/day. Still substantially lower than App Engine, but too high!
The server was then re-written in C++, using gloox, libcurl, openssl, and pthreads. Each message is dispatched to a threadpool. Blocking https calls are made to the App Engine server, and the results are then sent via ejabberd. This server is able to handle our max load (~ 12-16 inbound messages per second, resulting in around 400-600 outbound messages per second) at under 5% cpu load on a micro instance (at $0.02/hour).
The system is mostly stable (a lingering concurrency bug causes it to crash and automatically restart about once every 12 hours) and should provide us with substantial room to scale in the future.
Issues:
Google Apps for Your Domain has grown in popularity recently. This presents us with a problem; in order for XMPP messages to be delivered to users on a domain, a DNS SRV record needs to exist for this domain. Google does not automatically create this record, but messages between google apps domains get delivered correctly (so we never saw this issue with app engine).
Another issue that slowed down development a lot was that some clients (generally iTeleport) send invalid XML over the wire, which cause the python XML code to throw namespace exceptions. This made SleekXMPP even less reliable, and required making code changes in core Python libraries. The C++ libraries handle this gracefully.
Future work:
In the near future, we will be disabling old @partychat.appspot.com aliases. Other future work includes billing for large channels, and reducing the number of write operations on App Engine.
Conclusions
Working on this project has been quite educational. First of all, migrating a running service with many users from Google App Engine is hard, especially if it uses esoteric services, such as XMPP. Appscale is a reasonable platform that could help with the transition, but it is difficult to use, and may not be fully ready for production. Google App Engine’s insistence on a different paradigm for development makes migration extremely difficult, since moving to a new platform requires rearchitecting code.
An even bigger problem is the fact that some aspects of your system (e.g. XMPP domains) are not under your control. We had to migrate our users to a new chat domain, because Google did not allow us to point our domain elsewhere. This was a huge inconvenience for our users. Since our service is free, it was less of a big deal, but for an actual paid service, this would be a serious problem.
Since pricing is subject to rapid, arbitrary changes, and transitioning is difficult, no system that is likely to become productionized at scale should be written on App Engine. EC2’s monitoring and auto-scaling systems (more on this in a subsequent post) are excellent, and don’t require buying into a specific design paradigm. In fact, moving this proxy to a private server, or rackspace would be quite trivial.
Edit: I wanted to add this, just to clarify my point:
It's more than just a price/stability tradeoff. The problem is, as an App Engine user, one is totally at the mercy of any future price changes on App Engine because it is nearly impossible to seamlessly migrate away. The DNS aliases can only point to Google, and the API does not really work well on any other platform. So, at any time in the future, one's service could suddenly cost 10x as much, and one won't really have the option to move quickly. If one intends to scale, it's better to never get into that state in the first place, and develop on EC2 instead. If EC2 raises its prices (highly unlikely since computing power is increasing and costs are decreasing), one can always move to rackspace or just get a private server.
It's of course true that writing stuff on App Engine can sometimes require a lot less engineering work. But the difference is not really that substantial when compared to the possibility of being stuck on a platform that all of a sudden makes your company unprofitable. Changing a running service is very hard. Avoiding the problem by not getting stuck on App Engine is not trivial, but in my opinion the right call.
Migrated Partychat rooms and Google Apps domains
Due to App Engine cost changes, I've been working with the partychat folks to migrate our services to a new domain (new rooms are channel@im.partych.at).
We're seeing a lot of people who are using accounts on Google Apps domains having difficulty connecting to the new Partychat services.
Simple solutions
If you are using a Google Apps domain, these instructions (from Google) will help you get partychat working again. This will require help from someone with access to your domain settings (probably a system administrator).
If you don't have access to DNS records, or can't find someone who does, you will have to use a @gmail.com account instead.
Technical Details
Every domain needs to have a SRV DNS record to tell other XMPP servers where to connect (if the bare domain does has no record). The SRV record's name should be "_xmpp-server._tcp.domain.com." This doesn't just affect partychat, it prevents most people on non-Google third-party domains from being able to talk to you.
You can check if your server has one by executing the following (change mydomain.com to the name of your domain):
vijayp@ike:~/src$ nslookup
> set q=SRV
> _xmpp-server._tcp.mydomain.com
Server: 10.0.10.1
Address: 10.0.10.1#53
** server can't find _xmpp-server._tcp.mydomain.com: NXDOMAIN
As you can see, mydomain.com doesn't have a record, so our servers don't know where to send your chat messages. Here is an example of a properly configured domain:
vijayp@ike:~/src$ nslookup
> set q=SRV
> _xmpp-server._tcp.q00p.net
Server: 10.0.10.1
Address: 10.0.10.1#53
Non-authoritative answer:
_xmpp-server._tcp.q00p.net service = 5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp.q00p.net service = 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server._tcp.q00p.net service = 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server._tcp.q00p.net service = 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server._tcp.q00p.net service = 20 0 5269 xmpp-server4.l.google.com.
Why Eclipse’s “Check for Updates” is horribly slow (and how to fix it)
I recently installed Eclipse Indigo. I wanted to add a few plugins to it, so I tried to use the UI to check for new updates and install some new packages. I let it run for a while, and after about 45 minutes, it looked to be about 20% done. Eventually, it displayed a few errors about timing out.
The issue is that Eclipse appears to be trying to contact mirrors that don't have a proper copy of all the files it's expecting. My solution was to invoke eclipse with the following flag. Add it after "eclipse", or in eclipse.ini
-Declipse.p2.mirrors=false
Attaching a physical (raw) disk to VMWare Fusion 4 without BootCamp
I wanted to boot and run my Linux installation from a physical disk inside Mac OS X. There's no easy guide for this on the web; most want you to use a vmware tool that existed in previous versions in /Library/Application Support/VM* but that file didn't exist for me.
I think the new VMWare Fusion can read BootCamp config data automatically, but I didn't want to use BootCamp (long story). Since I had VirtualBox installed, this wasn't too difficult.
First off, figure out what the mac thinks your disk(s) are called:
chef:ubuntu_test.vmwarevm vijayp$ diskutil list
/dev/disk0
...
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: *64.0 GB disk1
/dev/disk2
...
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk3
1: Linux Swap 16.5 GB disk3s1
2: Microsoft Basic Data 983.5 GB disk3s2
3: Microsoft Basic Data Untitled 899.4 GB disk3s3
My main drive was /dev/disk1 (for some reason, I decided to use the entire disk for the linux partition) and the data partition was /dev/disk3s2.
After installing VMWare fusion 4, I created a new custom VM set up as Ubuntu 64-bit. This turned up in my Documents folder:
chef:~ vijayp$ cd ~/Documents/Virtual\ Machines.localized/
chef:Virtual Machines.localized vijayp$ ls
Ubuntu 64-bit.vmwarevm
chef:Virtual Machines.localized vijayp$ cd Ubuntu\ 64-bit.vmwarevm/
chef:Ubuntu 64-bit.vmwarevm vijayp$ ls
Ubuntu 64-bit-s001.vmdk Ubuntu 64-bit-s007.vmdk Ubuntu 64-bit.vmdk
Ubuntu 64-bit-s002.vmdk Ubuntu 64-bit-s008.vmdk Ubuntu 64-bit.vmsd
Ubuntu 64-bit-s003.vmdk Ubuntu 64-bit-s009.vmdk Ubuntu 64-bit.vmx
Ubuntu 64-bit-s004.vmdk Ubuntu 64-bit-s010.vmdk Ubuntu 64-bit.vmx.lck
Ubuntu 64-bit-s005.vmdk Ubuntu 64-bit-s011.vmdk Ubuntu 64-bit.vmxf
Ubuntu 64-bit-s006.vmdk Ubuntu 64-bit.plist vmware.log
VMWare has created a default disk that's striped into 11 pieces (see the *.vmdk files). In order to access the physical drives, I used virtualbox's toolkit:
chef:Ubuntu 64-bit.vmwarevm vijayp$ sudo VBoxManage internalcommands createrawvmdk -filename disk1.vmdk -rawdisk /dev/disk1
chef:Ubuntu 64-bit.vmwarevm vijayp$ sudo VBoxManage internalcommands createrawvmdk -filename disk3s2.vmdk -rawdisk /dev/disk3s2
chef:Ubuntu 64-bit.vmwarevm vijayp$ sudo chown $USER disk*.vmdk
Next you have to edit the VMWare file manually to add the disks, and remove the default one. I'm not sure why the UI won't let you select these vmdks, but it doesn't. Make sure the vm is NOT RUNNING, then edit the file. The diffs are pretty trivial:
@@ -2,16 +2,20 @@
config.version = "8"
virtualHW.version = "8"
vcpu.hotadd = "TRUE"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
+scsi1.present = "TRUE"
+scsi1.virtualDev = "lsilogic"
memsize = "1024"
mem.hotadd = "TRUE"
scsi0:0.present = "TRUE"
-scsi0:0.fileName = "Ubuntu 64-bit.vmdk"
+scsi0:0.fileName = "disk1.vmdk"
+scsi1:0.present = "TRUE"
+scsi1:0.fileName = "disk3s2.vmdk"
ide1:0.present = "TRUE"
-ide1:0.autodetect = "TRUE"
+ide1:0.fileName = "cdrom0"
ide1:0.deviceType = "cdrom-raw"
ethernet0.present = "TRUE"
ethernet0.connectionType = "nat"
ethernet0.virtualDev = "e1000"
ethernet0.wakeOnPcktRcv = "FALSE"
Now you can delete the Ubuntu 64-bit*.vmdk files.
I still haven't figured out how to set the UUID on these disks so linux mounts them correctly, but it's probably one of ddb.uuid.image and ddb.longContentID in the vmdk file. But it boots, so I can get some work done. I'll revisit the uuid stuff soon.
JetBlue stores plaintext passwords — and emails them too! Ugh.
I recently had a bad experience flying (or trying to fly, I guess) JetBlue. When I called in to ask for a refund on my ticket, the customer service agent and her supervisor were very helpful and gave me a credit. This resulted in an automated email from JetBlue telling me that a TravelBank account had been created for me. It contained my TravelBank account number, my email and my plaintext password from my Jetblue account!!
As anyone who knows anything about computer security would know, you should never, ever store plaintext passwords in a database. Not even because you want to let people recover their passwords when they forget them. And never never send them via e-mail, an insecure medium.
I've always been disappointed with the quality of JetBlue's website, but the fact that they have not even followed basic security procedures is really scary. This isn't just academic, Reddit did something similar and then lost a copy of their DB, which gave hackers a long list of (email, password) pairs. Since many people use the same password all over the place, this is especially dangerous -- having a very complex password may prevent hackers from figuring out your password from a hash, but is useless if they're stored as plain text.
If any developer at JetBlue is reading this, you really need to do the following:
- Stop emailing passwords in the clear
- Start storing passwords using something secure, like PBKDF1 (RFC 2898)
- Please don't use something like MD5 or SHA-128 for hashing passwords. Why? Read this thread.
I've changed my password and will avoid using JetBlue until they fix this.
This kind of thing really happens too often -- in fact, just recently Pingdom was discovered to store passwords similarly, and was widely criticized. So let this be a good lesson -- everyone should use different passwords for each different site, and we should just listen to XKCD's advice about passwords.
Here's the text of the email I received:
Thank you for choosing JetBlue and welcome to our new credit tool, Travel Bank. Travel Bank is an online account that allows customers to manage their credits with JetBlue. It will replace the current vouchers and credit shells that may be familiar to you. For our TrueBlue members however, TrueBlue points will still be managed as a part of the TrueBlue account. For more detailed information regarding Travel Bank and your credits, click here. A Travel Bank account has been created for you and transactions can be viewed online by clicking Here. Below you will find your account number and login information. Please keep this email as it is the only password notification you will receive. You will need to enter the following Travel Bank login ID and password when accessing your Travel Bank account online. Travel Bank Account Number: YYYYYYYYYYYYY Login ID: XXXXX Password: XXXXX
mounting large (> 2TB) hfsplus (mac) partitions on linux / ubuntu
I recently wanted to read an external drive which I'd formatted under Mac OS with Linux. Unfortunately, it was > 2TB, which seems to not be supported under Linux. It appears as if many of the vulnerabilities which used to exist (use of 32-bit values instead of 64-bit ones) seems to have been fixed, but the kernel still refuses to allow mounting. I figured out how to patch the kernel module to allow me to mount > 2TB partitions.
Important: I only intended to mount the partitions read-only, so I didn't go through the code carefully to ensure that it won't corrupt your data if you try to write to it! Use this at your own risk!!
- Using Ubuntu 11.04, upgrade to the latest kernel
- Next, unzip the source
- Next, patch the errant file; comment out the "goto out" code so it looks like this:
- Next, copy some files needed to build the module, and fix up the makefile:
- at this point, you should be able to run
insmod fs/hfsplus/hfsplus.ko
and then mount your hfsplus partition, using -oforce . please also use -oro for now.
root@mysterion:~# apt-get install linux-image-2.6.38-8-generic && apt-get install linux-headers-2.6.38-8-generic &&
apt-get install linux-source-2.6.38 && reboot
root@mysterion:~# cd /usr/src/linux-source-2.6.38
root@mysterion:/usr/src/linux-source-2.6.38# tar xfvp linux-source-2.6.38.tar.bz2
root@mysterion:/usr/src/linux-source-2.6.38# grep -A 3 supported linux-source-2.6.38/fs/hfsplus/wrapper.c
pr_err("hfs: volumes larger than 2TB are not supported yet\n");
//goto out;
}
root@mysterion:/usr/src/linux-source-2.6.38/linux-source-2.6.38# kernver=$(uname -r)
root@mysterion:/usr/src/linux-source-2.6.38/linux-source-2.6.38# kernextraver=$(echo $kernver | sed "s/$kernbase\(.*\)/\1/")
root@mysterion:/usr/src/linux-source-2.6.38/linux-source-2.6.38# sed -i "s/EXTRAVERSION = .*/EXTRAVERSION = $kernextraver/" Makefile
root@mysterion:/usr/src/linux-source-2.6.38/linux-source-2.6.38# cp /usr/src/linux-headers-2.6.38-8-generic/Module.symvers .
root@mysterion:/usr/src/linux-source-2.6.38/linux-source-2.6.38# cp /boot/config-2.6.38-8-generic .
root@mysterion:/usr/src/linux-source-2.6.38# make oldconfig && make prepare && make modules_prepare && make SUBDIRS=fs/hfsplus/ modules
Get control-left and control-right to move between words on Mac OS X
The default key bindings on OS X really annoy me to no end. The strange behaviour of home/end continue to confound me, but I finally figured out how to get Terminal, iTerm and iTerm2 to allow me to go between words using control-left and control-right. There are ways to do this by mucking around in various menus, but if you use bash, the simplest way is to add this to you ~/.inputrc file. It adds a bunch of different possible codes that various mac terminals might try to send instead of what bash normally expects for control-left and control-right.
I still haven't been able to fix this in non-terminal things (e.g. in Chrome control-left sends me to the beginning of the line), but I suppose this is a start!
chef:~ vijayp$ cat ~/.inputrc
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word
It turns out /etc/profile and basrc are insufficient for GUI apps. You have to add stuff to some plist for system-wide paths.
Anyway I needed ndk-build in my path for Eclipse to auto-build my JNI/android code, so I created this file:
chef:jni vijayp$ cat ~/.MacOSX/environment.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PATH</key>
<string>/Volumes/LargeMac/android/android-ndk-r5b/</string>
</dict>
</plist>