Jim's Depository

this code is not yet written
 

An January 20th iFixit published Apple’s Diabolical Plan to Screw Your iPhone about Apple’s evil pentalobular screws and their $10 kit to live with them.

As viral nerd stories go, it has everything. There is a powerful evil villain, an underdog hero, an articulate, attractive nerd (if you found the video), educational material, and a happy ending.

Let’s see how it turned out for them…

Alexa measures internet traffic with some system of taps and spies unknown to me. But you can ask it about a web site and see how their traffic fairs over time:

Google Trends will tell you how search term frequency is changing with time:

I think we can safely say that article tripled iFixit’s web traffic. It’s too soon to know the long term effects, but presumably some of those eyeballs were connected to memories that will come back when they need help repairing their devices.

Attachments

google-ifixit.png 23111 bytes
alexa-ifixit.png 35389 bytes

Another key life skill in place. The video at YouTube - Scientific Tuesdays - How to Breathe Fire Safely with Corn! covers it in both more and less detail than is required.

Most important hint: Exhale!

Second most important hint: have potable water on hand.

My hairline must have seen this coming, it has been getting out of the way for years.

I’ve spent all morning working on the next feature to be added to a piece of software I haven’t told you about. I finally added it by typing a string of 14 characters in one line of a source file.

I’m coding at about 30 minutes per keystroke.

Before one spends a good deal of time converting the RFCs into a well formatted EPUB with modern, legible typography… one should read RFC COPYRIGHTS & IPR.

I learned a new language (the actual purpose of the exercise), and had a grand time with fuzzy algorithms for deriving the intent behind the sequence of bytes, but ultimately, I can share it with no one and will not finish it. (Sorry Mechanical Turk, you will not get to labor away on my edge cases.)

Long story short on the RFCs: It doesn’t appear that anyone thought out the copyright issues for many years and now it is too hard to resolve it. 

Probably the best solution would be to find the 10% of RFCs that matter and build replacements with proper rights assignment and move on, or just live with them as is.

I’ve published tinycamd version 0.3.

tinycamd is a webcam program for Linux which makes Video4Linux2 devices available for http access. It is mind bogglingly efficient when using cameras with JPEG or MJPEG hardware compression. When using UVC (USB Video Class) cameras it includes a handy HTML 5 based page for adjusting the camera controls.

You can find the code at Google Code: tinycamd. You can read the attached man page.

Attachments

tinycamd.pdf 7363 bytes
I'm currently using a variety of cameras, but overall I find the UVC driver cameras to be most reliable under Linux. Having an actual specification that isn't reverse engineered from packet traces does wonders for quality.

I recently bought some WinBook WB-7144 HD webcams from microcenter at $30 for a two-pack. Cheap, reasonable quality, and solid driver support in Linux.


Hi Jim, FYI trying on a Linksys WRT160NL router with OpenWRT Backfire:

root@openwrt:~# tinycamd -d /dev/video0 -s 1280x720 -f 5 -F mjpeg -p 8090 -v
formating 1280x720 pf=MJPG
got format 1280x720 pf=MJPG
driver does not support VIDIOC_G_JPEGCOMP
fps=5
fps came out 1/5
Starting listener on 8090...
Failed to create watchdog for request thread: Success
Segmentation fault

I’ve written jpegapp which can be used to remove, insert, and extract the application specific segments of a JPEG file. I used it to embed transparency information in JPEGs, but you can use it however you like, some things that come to mind:

  • Remove EXIF or other strange camera information from JPEGs that you publish.
  • Attach source annotations to images when your create them automatically.
  • Yank out some application’s data to analyze.

A PDF of the man page is attached to this article.

You can find the source code over at google code jpegapp. BSD licensed. Enjoy.

Attachments

jpegapp.pdf 4474 bytes

I have written a program and some javascript to add alpha channels to JPEG images and render them correctly in modern browsers. 

The exposition requires some Javascript which femtoblogger does not allow, so I have documented the techniques on their own page: On adding alpha channels to JPEG images.

The code isn’t pretty yet, but it works.

I apologize for not testing on IE. The canvas based method should work with FlashCanvas per http://blog.jackadam.net/2010/alpha-jpegs/, but I don’t have the licenses to run the IE test images. (Wine will unpack the self extracting .EXE they insist on using as a shipping container, but VirtualBox has different emulated hardware from what the images expect and that leads to no network which cascades into avalanches of dialogs asking to download network drivers over the network that doesn’t exist and demands to register over the network with does not exist.)

Attachments

boot.gif 43981 bytes
weird, it's working on FF2 but not on IE6, but it's probably a matter of your JS code rather than the amazing technique you discovered :
Line: 218
Character: 3
Code: 0
Error Message: Expected identifier, string or number


Jim,

I realise you did this 2 years ago now, but this is really awesome. I'm a bit surprised there's not more attention drawn to:
  • adding transparency to the JPEG specification in a standards-based way and
  • your stop-gap solution.
This may certainly come in handy for some client one day, thank you for exploring this and developing tools for us to use even!

Just curious though, why are you using uncompressed PNGs for the alpha channel?  It would seem to me that embedding a grey-scale JPEG layer into the original JPEG would yield a much more compact solution and the benefits and pitfalls of lossfully compressing the alpha-channel should be very understood by the wielder of this solution.

Given the apparent intelligence reflected in your posts, it is obvious to me that you had already considered this, but yet you went with embedding a PNG into a JPEG.  Do you have a post somewhere that details your logic here?  If you're not interested in blogging about it, please drop a note at 'm' followed by 'j' followed by 'k' at sisuconsulting.com.  Many, many thanks in advance!

… and how to fix for Debian x86 users…

Anyone with a Western Digital Green Power drive should immediately check the Load_Cycle_Count in their S.M.A.R.T. data. This is the number of head parks. The drives are rated for 300000 over their lifetime, but the firmware parks the head after 8 seconds of idle time. If your computer wakes it up regularly you could wear out in a matter of weeks. Don’t panic a lot if yours is high. Mine drives varied from 30k to 1.5M before I figured this all out and stopped them from parking.

I know this because one of my rather new WD10EADS drives crapped out, causing a fairly unpleasant interruption in my mirrored root partition.

You can not use the standard ATA mechanisms for tuning drives to adjust this parameter.

There is a utility from Western Digital that you can use to change the timeout from 8 seconds to 300 seconds, which is probably enough to keep it from parking the head. Now, if you could run this on any operating system sold this millennium it would be pretty handy. Sadly, it runs only under DOS.

I’ve fixed the drives in three different computers, (and failed on three other drives), and it is an ugly process.

For people running Debian servers, these instructions will guide you through making a USB flash drive to boot DOS and run the WD utility.

  • Go to wdidle3, download the zip and unpack it to get the .exe.
  • Get a flash drive. I used a 256M one.
  • Put a MBR on it. Install syslinux-common, then dd /usr/lib/syslinux/mbr.bin onto the first block of your device.
  • Download a bootable image of freedos, perhaps this one: balder10.img
  • Boot a fake dos machine to format the usb key…
    qemu -boot a -fda balder10.img -hda /dev/sdX -k en-us
  • Use fdisk to make a single partition on the device. Then use format, and finally sys c:
  • Quit qemu, mount the /dev/sdX1 partition somewhere and copy the wdidle3.exe program on there too.
  • Now the ugly part comes up: Your BIOS is not your friend here. You will need to turn your SATA controllers to Legacy IDE mode. You will need to force your USB device to be handled as a hard disk, not a floppy. And of course make it boot off the USB.
  • wdidle3 /s300
  • wdidle3 /r
  • Dance, you deserve it.
  • Now remember to undo all the damage you wrought on your BIOS before you boot back to Debian.

Now, where you will fail is where you have a drive in a USB sled. Even my fancy USB sleds with S.M.A.R.T. support won’t let the drives be fixed. I suppose I need to take all that gear apart and temporarily rotate the drives through a server to repair them.

After piddling around with jQuery,CSS3, and the <canvas> tag for a week using only Safari 5 I decided to see how bad it was in Firefox. The comforting result was “not bad at all”.

Initially nothing rendered right, but that was all the first problem.

  • I was using a <base> with a relative URL, nice if you test in a subdirectory of your real server, but a mortal sin in the eyes of the W3C. Firefox caught me and ignored the directive.
  • My round corners and drop shadows were missing, but that is just because I didn’t add the -mozilla- variants. (I suppose I’ll make a CSS preprocessor to handle that as well as stripping my comments and white space.)
  • My @font-face fonts didn’t render in the <canvas> elements. The problem here is that there is no good way to tell a <canvas> tag to make sure it has the font loaded before it tries to get draw, and no way for your drawing code to check if the font is ready. (Safari can fail this race condition too, but it wasn’t happening to me so I didn’t notice it until I provoked it.)

    My solution is to defer any <canvas> drawing that uses text until after the $(window).load() fires. (Which you also can’t test for, and unlike .ready() won’t fire if the window is already loaded, so you have to add one to set your own ‘loaded’ flag.) This seems robust.

All in all I was pleasantly surprised. Two years ago the first browser change could be counted on to be a nightmare. Good work browser vendors!

The page in question looks like this:

  • Those meters are fully vector drawn in <canvas> at twice screen resolution to control pixelation artifacts and ensure a nice experience on \~300dpi devices. (\~12kbytes unminified and uncompressed, but that includes the pushbuttons and indicators as well which share code but aren’t on this page. Maybe 4k minified and compressed.)
  • The fonts are Droid and Molengo out of the Google Font Directory. A nice way to get some new fonts in play, but also have a high likelihood of a user already having them cached and serving them off a different hostname for more parallelism if not cached. (90k bytes)
  • I spent about an hour looking for a nice tileable brushed metal before giving up (after finding one only to discover the author didn’t know what tileable meant). I made this one in 5 minutes with gimp. (3.8k bytes)
  • Those meters also have color coding, but the sun is up and the batteries are full, so none of them are yellow or red.
  • Drawing the meters in <canvas> takes less bandwidth than sending images. For even a single meter, the code is smaller than the image would be, plus the code caches, so subsequent meter updates are nearly bandwidth free.
  • All told, the sources to that page are larger than the PNG screenshot, but the bulk of that is the fonts (90k) and jquery (22k). The uncached portion is 2.5k(800 on wire) for the index.html and 600 bytes for the AJAX query for the current data. Each of these comfortably fits in a single datagram.

Attachments

power.png 113783 bytes
First fly in the ointment: The iPhone 4 renders these gorgeously when zoomed in. The over sampling is beautiful. And you get to look at it for a long time as it more or less freezes MobileSafari when you zoom way in. The refresh after a small pan can be 10 seconds. Double-tapping to get back to a wide zoom frees you from this hell after the next redraw.

My new Western Digital Green 2TB (WDC WD20 EARS-00MVWB0) drives have 4k sectors, but they report as 512 byte for compatibility.  Linux 2.6.32 and the fdisk on squeeze will do the wrong thing by default and place partitions on bad boundaries.

fdisk -b 4096 -u /dev/XXXX

… is the right command to force the proper sector size. It will then die with a floating point exception unless you type a ‘c’ to disable MS-DOS compatibility mode once you are in fdisk.

(If you are just going to use them with LVM, maybe skip the silly label anyway and use the whole disk for LVM. Be careful though, currently on squeeze the lvm scan does not happen after the USB scan, so they won’t be found at reboot unless you do another scan, like in rc.local.)

more articles