No Updates To Archlinux?
How can it be? I've been without a single update for 2 weeks. Did all the developers go for vacation? And at the same time? Nay, it was a problem with the repo mirror that I was using (http://archlinux.unixheads.org/$repo/os/i686). I've switched to another mirror (http://distro.ibiblio.org/pub/linux/distributions/archlinux/$repo/os/i686) and everything is good again. Updated 200MB worth of packages yesterday.
How do I use Google’s Public DNS Servers?
Context: What are DNS Servers? From Wikipedia (read it in full):
An often used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, www.example.com translates to 208.77.188.166.
In short, if you're on the Internet, you are already using some DNS server - most probably the one provided by your ISP. Some more technically inclined folks may also be using OpenDNS servers.
Google announced just today that they are providing publicly hosted DNS servers. The motivation? Speeding up the Internet. It's is not the only effort to do so - see their SPDY protocol. So what is Google trying to achieve with its DNS servers? From the horse's mouth:
- Speed: Resolver-side cache misses are one of the primary contributors to sluggish DNS responses. Clever caching techniques can help increase the speed of these responses. Google Public DNS implements prefetching: before the TTL on a record expires, we refresh the record continuously, asychronously and independently of user requests for a large number of popular domains. This allows Google Public DNS to serve many DNS requests in the round trip time it takes a packet to travel to our servers and back.
- Security: DNS is vulnerable to spoofing attacks that can poison the cache of a nameserver and can route all its users to a malicious website. Until new protocols like DNSSEC get widely adopted, resolvers need to take additional measures to keep their caches secure. Google Public DNS makes it more difficult for attackers to spoof valid responses by randomizing the case of query names and including additional data in its DNS messages.
- Validity: Google Public DNS complies with the DNS standards and gives the user the exact response his or her computer expects without performing any blocking, filtering, or redirection that may hamper a user's browsing experience.
Out of the 3 things promised, I find validity interesting. Why? Because by controlling DNS servers, Google has the power to block, filter and redirect Internet traffic, but they promise not to do so. This is a big concern because the big G could've chosen the more 'cunning' way of redirecting unresolved hostnames to its search engine (redirection) or choose to filter out their competitors' traffic. I'm hoping Google is above such dirty tactics of course, they don't need to do so anyway.
Interested yet? See the guide on how to use Google's Public DNS.
Getting Around Issues With ‘repo sync’
If you've tried to download android sources, no doubt you would've came across this annoying message
'remote host hung up unexpectedly'
Basically what happened is that the source server is facing high-load, and decides to drop the connection. When this happens, you'll need to sync again.
I came across a hack for the script on this site and it looks like a valid workaround. The downside is that the script will now try to download even when there isn't a network connection. Funky.
Those that know me probably heard that I did manage to download the entire 2.3GB of sources. I actually forced the script to use one of the source mirrors instead of the main server. I added this to my /etc/hosts file (the IP belongs to android2.git.kernel.org)
204.152.191.45 android.git.kernel.org
While the connection did die, twice, I managed to download the entire thing. Since I was downloading in the middle of the night, I actually woke up to check on it every few hours...
Android 2.0 aka Eclair Runs on The G1
You'll need the new SDK for the emulator ROM or you can get it here [ROM] ECLAIR from SDK - xda-developers. Bad news: WiFi does not work and it does not come with any Google applications. Good news: Other stuff works and it fits in the paltry flash 
Cyanogen Mod: Android Applications And Mismatched UIDs
I recently switched from a vanilla JesusFreke Android ROM to Cyanogen. According to its creator, I would not need to do a wipe of my phone after the upgrade, so I did not (if things do go south, then I'd wipe). My only concern was in my more n00b days, I had Apps2SD installed and I ran it even though JF 1.51 already had a2sd support cooked in. I also had a massive incompatible theme installed. In short, I wasn't so sure my JF1.51 was vanilla enough to survive the switch to Cyanoge without a wipe.
True enough, my worse fears came true. After the flash, everything seemed fine. Things were going great as I got accustomed to the new snappy phone I had. This was until I tried using twidroid. For some reason, it would complain of connection issues, which was not possible as the browser and Market Place connected to the Web just fine. I then proceeded to reinstall the application only to find out that I can no longer install any applications from the Market Place.
To say that this was an extremely rude shock is an understatement.
Lucky for me, watching a nifty Google I/O presentation on how to debug Android thought me a few stuff. logcat for one. (Or did I read that from somewhere else? OK, nevermind that's beside the point)
To do this, I connected the phone to my PC and ran ./adb logcat while doing an install from the Market Place. Logcat showed that an error occured when DalvikVM tried to create its cache in /data/dalvik-cache. For some reasons unknown to me, it just didn't work. I tried checking for permissions but everything seemed fine. There was also a line regarding mismatched application UIDs, but more on that later. At this point, I was freaking out. I did not wanna wipe and reinstall the 40 or so applications (plus, I've gotten quite far in RoboDefence!) I had on my phone.
P/S: I'd like to show the exact error message but unfortunately, I neglected to copy the line from logcat before trying a fix. The successful message is below
I/installd( 1408): move /data/dalvik-cache/data@app@vmdl69624.tmp@classes.dex -> /data/dalvik-cache/data@app@com.twidroid.apk@classes.dex
With the error message, instead of an 'I' your get an 'E' (Info/Error) from installd and the error message is something along the lines of copying to /data/dalvik-cache failed (again, I hate myself for not copying the exact error message. Sorry). Android does not show this error message in your phone, just "Installation failed. Message: ". Yup, a blank message.
I also saw errors regarding mismatched application UIDs, that Android was expecting a certain value but the package being installed was of another. This happened only when I attempted to reinstall an existing application though (in my case, Twidroid).
Here's what I did to fix stuff.
For those familar with Cyanogen, he suggested that if there are any 'weird' issues after an upgrade with installed applications, such as applications disappearing from the Market Place's My Downloads list or you stop getting updates for your installed applications or you get force closes when running applications, you are to run a script called 'fix_permissions' that would... well, fix permissions. Actually, the issue is that Android rebuilds /data/system/packages.xml (with new UIDs) when the ROM is updated and in doing so, there is a mismatch of UIDs between packages.xml and what's in the /data/data directory. For details on what the script does, see this thread.
I ran the script in recovery mode and true enough, the mismatch UID problem went away. I also deleted my /data/dalvik-cache contents just in case there were file permission issues (they get generated again on boot). However on hindsight, I'm not too sure if this helped. Cyanogen has a script called a2sd in the /system/bin/ which does the copying/mounting/permissions during boot anyway.
Anyway, after those 2 steps, my phone was back to normal. Actually, it's really fast and snappy now thanks to Cyanogen. I'm not talking you-need-to-bencmark-to-see-it speed, I'm talking real-world the-browser-now-launches-super-fast kinda speed. Wished I switched from JF 1.51 earlier. So while upgrading to Cyanogen does have its dangers, I suspect the payoffs more than make up for them. Just check out the list of features that is cooked into his ROM! Worst case scenario - a wipe, small trade off if you ask me.
Yoono – Socialize Your Browser
I tweet (@ebernie), I'm on Facebook, I on gtalk, YM, MSN (ebernie@gmail.com, bernie.eng & ebernie@hotmail.com, respectively). I'm also on Flickr. Keeping abreast of things can be daunting at times. That's why sometimes it's neat (and more efficient) to have a centralized software to show me friend updates from the 6 social networks above. If you're like me, try out Yoono, a plugin for Firefox that allows you to sign in to all these networks and provide a centralized view to them.
The downside is it can get quite hungry with resources. Important if you run an underpowered machine, ignorable otherwise.
Yoono - Socialize Your Browser :: Add-ons for Firefox
