bkil vs. programming

I did some more investigation after the positive results with the TL-WR740Nv4  (click the link to get introduced to the way of recovery). Most users report that devices and firmware updates released after a point in time usually have this mode enabled. If a firmware update is available from the vendor for your device, it's a good idea to apply that update before installing OpenWRT or dd-wrt UNLESS you own something for which upgrading will ensure incompatible with OpenWrt, like a TL-WR730N , and possible some other models (please report). Note that some old models have newer updates in different languages, those may also be worth a try ( TODO : compatibility?). Also remember that later on, tftp recovery will need a type of firmware image without a boot loader, so strip it with dd if yours has it ( grep U-Boot , or check the filename). Positive reported claims so far (personal results highlighted): TL-WDR4300 router 192.168.0.86 server 192.168.0.66 query wdr4300v1_tp_recovery.b

I've found out that even this particular entry level router supports anti-bricking, so there's no need for soldering, unless of course you are modding. The method I used is the following: Set up a tftp server  on your PC and verify if it works correctly (configuration, permissions, firewalls, etc.) Rename your target firmware to wr740v4_tp_recovery.bin and copy it to your base folder (by default /tftpboot). I tested with openwrt-ar71xx-generic-tl-wr740n-v4-squashfs-factory.bin r43602. Set up the following static IP for your PC: 192.168.0.66 /255.255.255.0. If you're not sure about the firmware name on a different model, start a packet sniffer on your PC ( tcpdump -i eth0 -n -l ) and look for the name in the RRQ message. Preferably disconnect WAN from the router Connect the PC to a LAN port Power off the router Press and hold the reset button Power on the router After the leftmost (power) LED and the rightmost (padlock) LED turn on alone in a few seconds, release

I've just realized that stock Android 2.1 on the U20i (so called "mimmi") discovers Wifi networks by  passive scanning , and only sends out a few probe requests as an acceleration in case of opening the network list menu after waking up. On the other hand, it seems that both Pulse mini (Huawei U8110 with Android 2.1) and Mango (Xperia mini pro SK17i with Android 4.0.4) use normal active scanning. Common wisdom tells you that passive scanning potentially uses more power. This can happen because the receiver's low noise amplifier and processor can use as much power as the transmit circuit. This is especially plausible because maximum transmit power usually shouldn't exceed 100mW anyway (actually 20dBm EIRP ) which is in the ball park of the wireless chip's total consumption already, let alone the whole chipset or mobile device. Active probing involves sending out a probe request on each channel and listening for a response for a limited short interval. I guess

The correct usage of GnuPG (public key cryptography) is to offer a download link of your public key in every channel you communicate and also include your full fingerprint on your business card. It doesn't make sense in this combination to distribute either your key ID or your fingerprints electronically, because it opens up all kinds of bad practices involving trusting the unverified and confusion. Key servers and the web of trust itself erodes your privacy as your social relationships are publicly revealed, and your e-mail address is also opened up for easy spamming. However, a key server does make initial contact easier if you forgot to provide a link on the business card and it also enables key updates if you do use the web of trust by mutual key signing. No single solution is perfect for everybody. Note that both the PGP protocol and GnuPG internally reference a so-called 64-bit long key ID, however many tutorials erroneously use only the short key ID instead. Also note t

I have the fingerprint with me on paper slips if you'd like to verify any time. I also have a downloadable version . -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) mQENBFP4fKsBCADSCOuM1/Dtd9f52Pp0ZYVmjB4KkXisVpw5Qq3rEdXisC+xtreZ jwp0FKZnYnAudTFXHE1ZLFbFgO7A05d1N+JHJIz0ZRcYfG3mS2NO+J1yHBMZsq+n Z5HI+ZNpw3vONIVBBJM11e4hRNQ37HLOA78lUGgpf32J50BbAQ+xnncs1hr/4hvS v0EJDShbHZvBSQCxu73r7IE68ASZeTdnHKobhdWTOVza1xE6dOj/3EnB8pL2Ekno eckjOq2TxoUQCFKQjczw5cklqZjwjWHxSGgNZD71YSj/FXgd6twSDgyMfEg4Hs57 PPRfDdUcG9nsna5xDugm9/aXIejm0W9y8sINABEBAAG0O1Rob21hcyBOYWd5IChl bWFpbCBzaGExOiBhMzY3Zjc0MzU3MzVjNTA3NDdiMDAyNjU1MWJhZGYzYTIpiQE4 BBMBAgAiBQJT+HyrAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDy2MPO 03KDbXvACACR9dvQHt6SFJd7qE/uBO24hWYh56CBHRHWpIfT5/V1n0mdNNq8pf4/ KcqISQXQK+t3EijwUWgDVfkiy+eUq9yjCCSePsmg7t6nxZEyisikf6f1atZjA6fH S/+QvqPCG9CS9bIMdEpBrt2vehfY/vTEPOvIVWV0J0IhzxI6BzaTbWansmroRZpl WIyGnFkKdqr4tatcUSDNveA+LSW1k1Psi5AyZJ3oe2nNPBbVv+5FOGCpNE2UvVBs 5Zv0vNwMYdMt7Gc74uVSxDt

Seems like GmailThread.getId() isn't always persistent. What good is a primary key which can occasionally change its value ? I've now verified that this behavior is so unexpected that it is documented as well. The recommended workaround is to not use the Thread ID, but use the ID of each message instead. However, this gets messy as if you want a persistent reference to a thread, you need to do the following dance: var id = thread.getMessages()[0].getId(); // serialize id, and read it back later var thread2 = GmailApp.getMessageById(id).getThread(); Which kind of defeats the purpose of not needing to do slow fetching of all messages of each thread to draw conclusions about the thread itself  when processing a search result. Yes, I'm trying to simulate Gmail filters by hand and need to watch out for quotas. I think I'm going for a hack based on getFirstMessageSubject() and/or getPermaLink(). And before you ask: no, there is no such thing as getThreadByPermaLink()

I'm still considering which of these would be the most preferred for a beginner showing off talent: HelioHost unlimited CPU, RAM, MySQL, bandwidth, 500MB disk, 2 cron jobs/day PythonAnywhere 100sec/day prioritized CPU, 512MB RAM, 1 daily task, low bandwidth, Internet whitelist OpenShift 3 gears of 1GB disk and 512MB RAM each AlwaysData 64MB RAM, 1GB/month traffic, 10MB disk, non-commercial use only

If you ever felt that Transport Tycoon or Railroad Tycoon made you do too much micromanagement, this is just the kind game for you. In trAInsported, your mission is to write an AI that optimizes traffic better than your opponents. Although, it makes me sad to see such an influential project being hosted via vaporware methods. Setting up any kind of free shared hosting and embedding the small dynamic scoreboard and match parts via an iframe would be trivial. Caching daily stats would also be a good idea. A simple solution would be to use github.io to host the site directly from the repository, which would be both durable and scalable. For the record, if anything happens to the project, here are some relevant pointers: Official (dynamic DNS) site and scoreboard  supposedly running on a Raspberry Pi Source code, documentation, wiki at  github Forum at  indiedb Introduction at  moddb History at  yellloh Summary at  love2d Featured on  indiegames Featured on  gamingonlinux A

I collect none of your personal information other than the comments that you type in response to a post. You retain your copyright to your comments, but I reserve the right to remove any or all of your comments without reason. I also reserve the right to reply. :) Google is hosting this blog for me via the Blogger infrastructure. Note that I am given access to limited statistics from some of the basic data, like the web browser you use and such. Please refer to Google's privacy policy for more information on the kind of information they gather. http://www.google.com/intl/en/policies/privacy/

Installing a Huawei E352 HSPA+ dongle took ages under Windows. I had to abort it halfway through because I was running out of time. In retrospective, it was probably caused by a conflict with the previous modem's connection dashboard. I was shocked when I wanted to resume next time. Some time after inserting the device, the system asked for a .sys file from a driver disk. Neither modem worked anymore. As usual for this kind of dongle, no vendor download is available as the device itself contains all drivers on a virtual CD-ROM. However, that is only accessible before it's  switched to modem mode  by the parts already installed. Chicken and egg problem. Puppy Linux to the rescue! Thankfully, I had it on my USB flash along with DSL and SliTaz . The system loaded to RAM rapidly. I copied over the drivers from the modem to another USB flash. As a plaything, I enjoyed the command line and the responsivity, also browsing the web a bit over 3G. After rebooting to Windows, reinstal

I've just discovered that newer devices and networks probably don't need my latency hack anymore described in  making your 3G cellular mobile Internet 10x faster for free . According to this overview , the following features introduced for Evolved HSPA (or HSPA+) in 3GPP Release 7 could theoretically fix the issues I've uncovered: Continuous packet connectivity :   With much of the data traffic being in the form of IP data, continuous connectivity is an increasing requirement. To achieve this the HS-DSCH and E0DCH channels have been reconfigured to enable them to be rapidly able to transmit user data. Enhanced CELL_FACH operation:   This enhanced operation is required to assist in maintaining the always-on packet connectivity during periods when there have been little or no activity.

The described method should work on even simple desktop environments. If I don't already have an xorg.conf for editing, I first generate it by  Xorg -config xorg.conf.new . To make the screen easier to read, you need to  scale DPI by setting Displaysize in the respective "Monitor" section of xorg.conf proportionally larger than it physically is. A native driver outputs the original image size in Xorg.0.log. You need to type in the real size values times the magnification factor. So if the real active area of your display is 200mm wide and 100mm high and want 1.5x larger text, you insert  Option DisplaySize 300 150 . Unfortunately, not all applications honor this setting. You need to increase the default zoom by hand in  Chromium . You need to update the hexadecimal "LogPixels" dpi setting in ~/.wine/system.reg for  Wine . Otherwise if you are using Gnome, you could also try to increase the text scaling factor with the Gnome Tweak Tool, Universal Access or

It worked easily with the VESA driver, however the legacy mode tables don't have any of today's fancy aspect ratios. OpenChrome, the default driver, just gave a blank screen. Reviewing Xorg.log revealed an abort by signal 11, segmentation fault (segfault). Let me share the process of fixing it. I went on to generate a new xorg.conf for editing by Xorg -config xorg.conf.new . I then proceeded to add as much fail-safe options as possible from the driver documentation : Section "Device" Option "ModeSwitchMethod" "legacy" # or blank & segfault Option "SWCursor" "true" # unsure Option "EnableAGPDMA" "True" # unsure Option "NoAccel" # or starts to lag after some time Identifier "IGP" Driver "openchrome" BusID "PCI:1:0:0" EndSection Section "Module" # unsure Disable &

Works perfectly with two smarter routers using default settings, but does the well known Android Ice Cream Sandwich dance on a legacy one. It sometimes connects on first attempt, other times after a dozen loops, in the rest of the cases not at all. A loop consists of saved, connecting, authenticating, obtaining IP and scanning. The signal strength goes very low in the authenticating and obtaining IP phases. It spends most of the time displaying obtaining IP address, which takes a few seconds. Lowering the beacon interval does help a bit. Altering channel selection, RTS, TKIP, MAC filtering, preamble type, IAPP, data rate or G-only vs. B/G doesn't make much of a difference. A timing issue related bug in the wireless driver is probable, as loading the router CPU sometimes helps. The router log is filled with the following actions 3 second apart: "syslog: wlan0: WPA2-AES PSK authentication in progress.." Sprinkled with authentication failed and "udhcpd Received a