Ordered

Interesting

Disclaimer: All links are redirected to dx.com with my affiliated ID.

However, he continues: “The whole episode shows once again that something is seriously wrong with the current implementation of the DMCA takedown system. At the moment rightsholders get to take down whatever they want, with almost no oversight and no incentive to improve the accuracy of their systems”.

On the positive side, the free documentary is getting some extra publicity. It can be downloaded from The Pirate Bay, completely legal, if you live in a country which still allows you access to that site, that is. However, you can also get it and contribute on its official web site, watch on YouTube, or read up on it on IMDB or Wikipedia.

Another interesting and instructive video is Kevin Darrah’s on a 8×8x8 RGB cube. (Unfortunately, it wont show in HTML5 yet, but can be downloaded with the Video DownloadHelper Firefox plugin). He explains how to construct the towers which make up the cube, and also goes into detail on testing the LED and connections along the way. Much more work, of course, but also looks very cool.

“The Aleph was about two to three centimetres in diameter, but all of cosmic space was there, with no diminution in size. Each thing was infinite, because I could clearly see it from every point on the universe”.
Jorge Luis Borges, ‘The Aleph’

Borges’ short story, as many of his stories, has a melancholic slow phased plot, filled with references, both implicit and explicit, part fictional part real. It is because of Borges’ emphasis on references that it is interesting to see what another author makes of a reference back to Borges. Indeed, as Borges pointed out in “Kafka and His Precursors’”: “The fact is that every writer creates his own precursors. His work modifies our conception of the past, as it will modify the future.”

So how does Coelho’s work stand up? Unfortunately, I’d say he falls short. Although the Aleph is a central plot device, it does not create a significant reference to Borges, so it ends up feeling slightly pretentious to invoke it. Coelho’s Aleph is of a slightly different kind than Borges’ in that it is not a tangible object, but rather a specific point in time and space, created by the presence of specific individuals. It has the added property of carrying those individuals (or at least in their minds) to a different point in time, in a previous life, where they re-experience a disastrous event.

The bulk of the story centers around the various personal drama of the party travelling by the Trans-Siberian Express, and the main character’s (supposedly Coelho himself) struggle to resolve the conflict in his previous life, within the Aleph. Throw in a bit of populist self motivation and realization, plus some sexual fantasies (because sex sells, right), and we have another Coelho success. It’s an easy read, if you manage to ignore the pretentious “grand motivational speeches”.

If there’s anything to be taken away from Coelho’s advice in the book, it’s that a warm relaxing shower is a perfect time for reflection and peace of mind. Then again, if you haven’t figured that out by now, you probably have a rare case of severe aquaphobia, or you might want to change your boiler.

To sum up, “Aleph” disappointed, and if it hadn’t been for the Borges reference, it wouldn’t have been of much interest at all. It is a typical Coelho formula to fame and riches: a feel-good populist message, an easy read, and the appearance of intellectual content.

From a technical perspective, it is not clear what kind of unlocking is performed; whether it is the SIM code, screen lock, or account password. It is interesting that the article mentions decryption, but it is probably a misunderstanding, or wrong wording: Android phones do not use encrypted storage by default, and in fact, if you have a model with a removable memory card, you can read that in any SD card reader. Accessing the embedded phone storage is also easy if it already unlocked (using fastboot / adb). iPhones does not use encrypted storage by default either, to be best of my knowledge. The article does indeed state that “It’s not clear whether that means Apple has created a backdoor for police [...] , or whether it simply is more skilled at using the same procedures available to the government.”.

From a privacy and security point of view, it is clear that it is irrelevant what the default security setting is. It can simply not be trusted to perform the task a user would expect. Rather, one should use take matters into own hands, and use software that has been proven to not contain backdoors for police or others. The only option is free and open source software, which has been vetted by security experts and the community.

4.3″ Resistive Screen Android 4.0 – $43

7″ Capacitive Screen Android 4.1 – $62

10.1″ Capacitive Screen Android 4.0 – $169

On the bright side, 4 TB disks are now really taking off, with the Seagate Barracuda 4 TB now just marginally more expensive than the WD Green 3 TB in terms of bucks per GB. Also interesting, is the WD Red offering, which at only 10 Euros difference to the Green 3 TB counterpart now looks like a very good deal. The difference is the manufacturer warranty at 3 vs. 2/1 years, but also in number of platters, 3 for the former, while Green is still on 4 x 750 GB (as far as I know). Since my old HD is shown critical signs of ageing, I might just pick up one of those.

Finally, I’ve also updated the long term history chart at hblok.net/storage. Again, somewhat sideways movement for some of the items.

Exchange rate: 1 Euro = 1.230000 CHF.

Also interesting is a an overview of the arguments against DRM, over at the Free Culture Foundation blog.

However, for all the imagined scenarios, they fail to mention the second elephant: the US, and its heavy handed way of forcing other nations to filter and police their net-citizen, in the interest of US content “owners”. Through international trade agreements (e.g. ACTA); covert diplomacy (e.g. Russian AllOfMp3, and Swedish Pirate Bay raid and court case, and blocking in many countries); and boots on the ground in the MegaUpload raid, to give a few examples, the US is shaping the Internet and international law in their economic interests.

Schmidt and Cohen also speculate that in the future, Internet access will require some form of “passport”, and visiting other “regions” would require an “Internet visa”. Users would be forced to register before they’d gain access, they imagine. Well, Mr. Schmidt, that is happening right now. In Germany, hotel owners have been pressured into registering, with signature, every device they let on their network, so that they are not finned for “illegal” activity of their guests. Again, it is US business interests who have forced through this kind of filtering and surveillance.

Indeed, there are many unfortunate scenarios which might remove the value of the Internet for some users. However, we don’t have to come up with hypothetical scenarios, and point fingers at “other nations”. Instead, first take the plank out of your own eye, and then you will see clearly to remove the speck from your brother’s eye.

Secondly, even without these surveillance tactics in place, connecting to the abundance of half-open WiFi networks without authenticating can be useful. They are open in the sense that WiFi encryption is not used, and you can acquire a local IP without password. Most of the time, these networks are set up with a local log-in page, which grants you access for a specific device (MAC based) typically for a fixed amount of time. However, before the authentication code and password is entered, some traffic is let through: DNS requests have to work to get to the log-in page, and local hotel page. This is the basis of several TCP/IP over DNS protocols. I choice iodine, and successfully used the hotel network without log-in.

iodine is a bespoke server/client protocol which lets you tunnel IP4 data over DNS requests/responses. It works by setting up an extra network interface (TUN/TAP device) on both server and client, so that any traffic can be tunnelled. It takes care of a lot of the nitty-gritty settings itself, and probes for best settings. Finally, iodine is available for most popular platforms, including GNU/Linux (in the default repositories of Fedora and Ubuntu), *BSD, Android. However, make sure the same version is running on both client and server, as the author states that compatibility between versions is not a project goal.

Detailed setup is covered by several people, including their own HowTo and README; a CentOS compile example; and one for Debian. Thus, I wont repeat those details, and only cover some of the gotchas I stumbled upon and lessons I learnt:

1. Start small and expand: The client/server can be brought up on the same machine, so make sure to try that first. Then try on the same local network, or remote but open networks, and finally on a semi-open network.
2. Watch your firewall! The default DNS port, 53, is typically blocked, so you’ll have to punch through and forward that. Also make sure you open for UDP on that port! Use nmap from different locations to confirm that the port is open throughout. nc (Netcat) is useful in debugging the connection, but again make sure it’s UDP.
3. Make sure the DNS entries for your domain are correct. You need two entries, and with some providers, it might not be obvious how to fill in their web-form to achieve the exact settings. I found this example most helpful.
4. Debug the DNS setup using the CLI command dig, and the DNS web-tool by MXTools. For dig usage, this comment was useful.
5. Use the test page provided by the author of iodine. It gives detailed and useful error reports on how far you’ve come with your setup.

With some luck, you’ll have a working setup, and will now be prepared for the next time the hotel receptionist does not give you enough WiFi vouchers for all your devices. Having said that, it does not really replace full access, as the connection will be “modem-slow”, or even worse. However, you do get access, which is sometimes what counts.

A client is is also available for Android from iodine, and Marcel goes into details on how to compile and run. I’ve not tried yet, and it seems there’s room for an easy to install F-Droid package there. More about that later.

What’s perhaps more interesting, is Arthur’s observation that Rubin was in fact a proponent of open source, and Android as a free platform, even though that was difficult to see at times. Arthur contrasts Rubin’s stance against Google’s and possibly Sundar Pichai’s (Rubin’s succeeder) desire to control the Android ecosystem. That path could conflict with handset manufacturer’s wish to brand and distinguish their products from their competitors. Arthur points out that about half of the 145m Android phones shipped in Q4 2012 were in fact not Google enabled (with a Google account, Gmail, etc). He speculates that the logical move for Pichai is to tighten control of the platform; making it less open.

That brings us to another headline: The general fight for control of devices, not just mobile phones, and the right to do whatever we want with the hardware we’ve bought, paid for and own. Kyle Wiens makes the case that we should be allowed to unlock any device, with tractors and cars as prime examples. These farmer and household items have become so complex to repair and maintain, that independent mechanics can no longer do the work. And even if they could, they are barred from access to embedded computers, sometimes based on proprietary tools and software, but also based on copyright, of all things. The access codes (passwords) are copyrighted, as are the service manuals, and only licensed technicians are granted access.

So are we headed towards the locked down nightmare Stallman warned us about sixteen years ago in his 1997 easy “The Right to Read”? If we keep letting mega-corporations have their way, that is a danger. However, as Wiens points out, Massachusetts passed Right to Repair legislation to make it possible to repair automobiles; other states are following. The White House petition to make it legal to unlock mobile phones did get a response, however, it is unclear if it is enough to avoid the criminal law which now applies to phone unlocking. Maybe there is still hope.

Many users feel betrayed, however as Alex Kantrowitz points out in Forbes, none of them actually paid for the Reader services, and thus the feeling of ownership is misplaces. As the old cliché goes: If as a user of a web service you don’t pay, you are the product, not the customer. You’d think some have learnt by now, but it will take many more of these stories before that message is clear.

So are the alternatives? Well, but of course there are! Many of them! Each user will have to decide for himself what fits his purpose and use best, but that’s a choice which is worth appreciating. Some will maybe continue with a web service style application, while others have learnt that “the cloud” can evaporate right in front of their eyes, with little chance of saving the remains of what once was.

The myths about how you should use an SSD, and what you should not do with it keep on spinning. Even if there are frequent articles which crunch the actual numbers, the superstition persists. Back in 2008, Robert Penz concluded that your 64 GB SSD could be used for swap, a journalling file system, and consumer level logging, and still last between 20 and 50 years under extreme use.

Fast forward to 2013, with 120 and 240 GB drives becoming affordable, the problem should have virtually disappeared from consumer grade hardware, but people are still worried. So when Magnus Deininger did some estimates on SSD stress testing, he got flack from Slashdot since he did not cover the consumer level disks. The write endurance and number of estimated write cycles on a single block before it goes bad varies widely between consumer and enterprise grade disks, ranging from only 1000 cycles to a million. This article from Centon explains why that is. As can be seen from the simplified figure below, the cheaper consumer drives using “TLC” (Three Layer Cell) or “MLC” (Multi Layer Cell) memory cram the data a lot closer, and thus degrade quicker than enterprise grade “SLC” (Single Layer Cell) memory.

Stress test of consumer SSD

Deininger concerned himself only with the high end drives, with 100k to 1M write cycles, while most folks over at Slashdot seems to have the low end ones, at 1k – 10k write cycles, and thus the furore. However, Deininger’s estimates were also skewed against the high end drives, since he used the maximum write speed of the SATA 3 controller, which at 6 Gbit/s (750 MByte/s) is lot more than the ~500 MB/s a typical SSD is rated for, or the ~250 MB/s you probably get out of it on a consumer system. And even that is still estimates for a stress tests, and does not even start to model a typical consumer usage pattern.

Deininger goes into detail on how he came up with the estimates, and also how to plot his graphs in Gnuplot. So based on that, let’s run a few numbers, covering the 10k and 1k disks and typical use. However, let’s first drop the stress test write speed down from max controller speed to typical system speed of 250 MB/s. Also, for his plots, he uses multiples of 1024, which for flash memory based drives might be correct, but is not universally used; for example Intel specifies in GB (base 10), while OCZ in GiB (base 2). For transfer speed, this is wrong, as base 10 is the norm. Although it does not make a big difference, I’ve changed to base 10 numbers.

The graphs show time on the x-axis (days on the two first, and years in the next section), and the fraction of broken memory cells (or blocks) on the y-axis. That is, from 0 damaged cells, to 100% or all of them at the top. A horizontal lines marks the 10% point in all graphs since this is usually the point where damaged cells will be visible to the end user. Before that, the internal write levelling on the disk controller will hide these cells, since most disks come with about 10% space reserved for this. (Thus a disk with 128 GiB space is sold as 120 GB, and 256 GiB is sold as 240 GB).

First, there are a few fundamentals based on Deininger equations which can be seen in his examples, and also becomes clear in the graphs above: Doubling storage capacity of the drive doubles the time to failure (at the 10% line). And increasing flash lifespan by a factor of ten also increases time to failure by a factor of ten. All linear relationships, and no magic there, in other words.

For the three drive sizes considered (I dropped the 32 GB size, as I did not find it worthwhile for almost any application any more), the failure times at 10.000 write cycles are 26, 51, and 103 days for 64, 128 and 256 GB respectively. For TLC memory, at only 1000 cycles, the times are thus also a tenth; 2.6, 5.1 and 10.3 days.

If you were to conduct a stress test of drives from different manufactures, these numbers would be interesting. You could for example do the write, check and remove operations continuously till you start to see errors on the data written. However, as read speeds are typically around the same as write speeds for most SSDs, it would actually take at least twice as long as the points in these graphs. (The remove operation also has to be factored in, but is only a fraction of full read and write).

Typical usage

For any performance test it is important to understand where the critical failure points are. However, it does still not tell us what will happen on a typical home user system. A typical consumer would not fill up his whole drive multiple times a day, only to remove it all and start over. So how best to simulate typical user behaviour. Well, we could of course just leave the drive in a machine, and run user software over many years to see what happens. That would not be practical, as we’d never get any useful results in a reasonable time. So, we’re left with estimates, but at a different write speed than the stress test above.

How much would a typical user write to his disk? There will be different use cases of course, but let’s assume two scenarios: a low to medium use case, where 1 GB is written every day, and a heavy home user who writes 1 GB an hour, every day (although, even that is probably beyond what could be labelled as consumer usage). At this point, a table of the different speeds and units comes in handy, so we can wrap our head around the numbers. It then becomes clear how extreme the 250 MB/s stress test actually is, as it will fill up a 64 GB disk 337 times over in 24 hours (250 MB/s * (24*60*60) second = 21600 GB. And 21600 / 64 GB = 337.5 times).

Now for some graphs. You’ll have to watch them carefully as the plotted lines are all the same, the y-axis are all the same, the disk sizes are the same, and the only parameters changing are write speed; 1 GB vs. 24 GB a day, and cell cycle life span; 10k vs. 1k. And watch out for the x-axis which are now in years, instead of days above. The first graph shows 10k write cycle disks, where 1 GB is written every day. The smallest disk, at 64 GB, will then last for 1524 years!

Can that be right, you ask? There must be some a mistake in the numbers somewhere? Well, let’s do a quick check to see if it matches Deininger’s graphs: First, his plots were in days, so 1524 years makes 1524 * 365 = 556260 days. Next, the ratio between 6 GBit/s and 1 GByte / day we get from the table above: 64800 (GB / day). Finally, In his first graph, he considered 100k write cycle disks, so we multiply by a factor of 10. Plug in the numbers: 556260 / 64800 * 10 = 86. Exactly matching 86 days for the 64 GB disk at 100k cycles in his first graph. The math works out.

Even in the most unrealistic use case, where a 64 GB drive rated for 1000 write cycles (TLC memory) is filled up almost three times per week, it will last more than six years before the first dead memory cells are likely to show. Moving to a MLC based drive at 10k (still consumer grade), the time to failure moves to 63 years, most likely far outlasting the system it was hosted in, or maybe even the consumer who bought it.

(For the Gnuplot scripts to generate all the graphs above, please see this file).

Conclusion

So will Sold State Drives last till the end of time? Of course not! In fact, plenty of other components are prone to fail just the same way as in old HDDs: Capacitors are infamous for their short lifespan; solder joins might crack. The important point is, it is not the memory cells which are likely to fail first, even under the most extreme use.

Still, it makes sense to deploy tools fit for purpose: An enterprise drive drive using SLC memory, with 100k or 1M write cycles will leave all doubts behind. There will be no need to consider special use cases or take special precautions (beyond normal backup and security procedures which should be in place regardless of drive type). For the home user, the same is true: Even the smallest drives with shortest cell lifespan will not fail under normal use.

More specifically, there are no problems or worries with

• using ext3, ext4 or other journalling file systems on an SSD.
• storing /tmp or logs on the SSD.
• using an SSD partition for memory swap.
• any normal consumer usage pattern.

In summary: Exchanging the old spinning disk with solid state will pose no extra risk of data loss. It will of course not reduce the risk of loss from other threats either, so normal backup and security procedures should always be in place.

Well, the article also mentions a few similar stories from “The Land of the Free”, where digging your own ditch is now legislated against. In the interest of the free market economy, of course. Parallels are drawn to big company lobbying and FUD in the late 19th and early 20th centuries, when rural communities formed their own electric utilities. It states optimistically that there are to this day thousands of local communities with local electric services, but also that most of it was (and is) consolidated into a small group of companies.

Another interesting approach to Internet build-out which is mentioned is Google’s Fiber project, with Kansas City as the Guinea pig. However, there the roll-out is in “big company” fashion, with marketing “threats” of missing the boat if they don’t sign up NOW. Not your friendly farmer dig-out, in other words.

Regardless of strategy though, the local, sometimes DIY, approach to physical layer last-mile build-out fits very well with the scale-free network topology of the Internet. It is with this kind of ungoverned and unplanned growth it thrives best. Legislating against it of course make no sense at all, but waiting for a big tele or cable company to do the job should really not be encouraged either.

Again, small and decentralized triumphs over big and inefficient. It’s simply the way of the future.

Now there is also a public face to this, in the form of a new initiative: The CitizenWeb Project.

“The CitizenWeb Project is a mission to fight for a free, open, and above all a decentralized Internet. In order to achieve this, it aims to empower everyday internet users with the information and resources they need to take matters into their own hands. We seek to spread the word about how to secure yourself online and how to declare “digital independence” in this age of the Google hivemind and Facebook privacy nightmares. While these services may be convenient, they carry very dangerous implications for our freedoms. This is only getting worse with time, as the corporations behind these services become entangled and indiscernable from government services and real-life social obligation. And it is only getting worse for the most sensitive users: journalists, activists, muckrakers and whistleblowers.

There are viable alternatives to these invasive and ubiquitous services. The CitizenWeb Project is therefore focused on giving the tools to each individual user to become an independent “citizen” of the Web — to decentralize their social networks and platforms, to become the TRUE owners of their data, and to communicate and network in security.”

On an international scale it gets even more interesting. For their reluctance to comply with US law, Spain and Canada have been put on a special US “watch list”. Now, in Spain’s case, it is interesting that it seems it is actually legal to both upload and download copyrighted material, as long as it is not for commercial profit. Being on this “watch list” is in fact a sign of living in a country that care more about their citizens than old fat American corporations.

So, make sure you pirate to contribute to a free society, and get your country listed as a free nation.

Enjoy your weekend!

From left to right, the mobile phones run Android apps which present a simple interface to control the lights. Each light can be turned on and off individually, or by some pre-sets (e.g. everything on or off, “good morning”, or “movie time”). The application has hard-wired the IP address of my always on server / PC on the local network. There is of course nothing stopping me from connection to a public IP (and port-forward), however, I don’t need away-from-home control at this point. The phone app simply sends a “light switch command” to the PC, which forwards it directly to the Arduino (see details below).

In this setup, the server is only a proxy, however, it could of course also be used to implement pre-programmed settings. E.g. daily rhythm commands when we’re away on holiday, or other automated functions. Since this box is also my PC, I can also send commands directly to the Arduino over serial /dev/tty; I have some convenience bash-scripts for that. For the phone app, it only does the forwarding on a hard-wired port:

while true; do nc -l 1234 > /dev/ttyUSB0; done

Maybe that bit could be improved in the future. Especially, since there are occasionally a few hiccups in the phone to PC communication. For example, the switch from 3G to local Wifi connection might be delayed as we enter the house, so commands will buffer up, and then suddenly sent en masse. Also, this would be a natural place to expand the system with pre-programmed actions. It should also be noted that to get this to work, I had to enable communication on the port 1234 both on the Wifi router, and the local server firewall.

Finally, the Arduino, connected via USB, accepts the incoming serial messages. The encoding is simple: A two digit code where the first digit is the index of the light, and the second is 0 or 1 for off or on (see the loop() method in the source listing below). So, “11″ will turn on the first light, while “10203040″ turns off all four lights. (Note that in the code below, to make things clearer for myself, index 0 is skipped).

The code below is all there is the the Arduino part. It hard-codes the Everflourish messages and timings. It should be noted that the messages as found in the previous article, are most likely some form of Manchester code, as there are always pairs of 01 or 10. Thus, the hard-coded messages could have been shortened, but this would have added (a bit) to the complexity of the code, so I left it.

The main loop waits for incoming bytes on the serial USB connection, and sends the according light switch command to the RF transmitter on pin 2. Here there is probably also room for some improvements, to avoid illegal numbers, stuck states, etc. Once a valid code is received, the transmitted signal for that button is repeated four times, just as seen with the original remote control.

(Download source)

#define OUT_PIN 2

// Timings in micro seconds
#define SHORT_UP_0 567
#define LONG_UP_1 1134
#define DOWN_SPACE 680
#define UP_END 15000

const int PREAMBLE = {0x00};
const int OFF[] = {0x55};
const int ON[]  = {0xaa};

const int light_array[][5] = {
  {},
  // main
  {0x65, 0xa9, 0x46, 0x95, 0x67, },
  {0x65, 0xa9, 0x46, 0x96, 0x96, },
  {0x65, 0xa9, 0x46, 0x99, 0xa3, },
  {0x65, 0xa9, 0x46, 0x9a, 0x61, },

  // aux
  {0x65, 0xa9, 0x46, 0x95, 0xaa, },
  {0x65, 0xa9, 0x46, 0x96, 0x53, },
  {0x65, 0xa9, 0x46, 0x99, 0x62, },
  {0x65, 0xa9, 0x46, 0x9a, 0xa1, },
}; 

void setup() {
    Serial.begin(9600);
    Serial.println("setup");

    pinMode(OUT_PIN, OUTPUT);
}

void loop() {
  if (Serial.available() > 1) {
     int light_id = Serial.read() - '0';
     int on = Serial.read() - '0';
     Serial.print(light_id);
     Serial.println(on);

     for(int i = 0; i < 5; i++) {
       send(light_array[light_id], on);
     }

     //delay(500);
  }
}

void send(const int *light_data, boolean on) {

  digitalWrite(OUT_PIN, LOW);
  delayMicroseconds(LONG_UP_1);

  send_bytes(PREAMBLE, 1, 4);
  send_bytes(light_data, 5, 8);
  send_bytes(on ? ON : OFF, 1, 8);

  digitalWrite(OUT_PIN, HIGH);
  delayMicroseconds(DOWN_SPACE);

  digitalWrite(OUT_PIN, LOW);
  delayMicroseconds(UP_END);

  digitalWrite(OUT_PIN, HIGH);
}

void send_bytes(const int *bytes, int len_bytes, int len_bits) {
  for(int b = 0; b < len_bytes; b++) {
    int data_byte = bytes[b];
    for(int i = len_bits - 1; i >= 0; i--) {
      digitalWrite(OUT_PIN, HIGH);
      delayMicroseconds(DOWN_SPACE);

      digitalWrite(OUT_PIN, LOW);
      int data_bit = ((data_byte >> i) & 1);
      if (data_bit == 0) {
        delayMicroseconds(SHORT_UP_0);
      } else {
        delayMicroseconds(LONG_UP_1);
      }
    }
  }
}

If you don’t want to build yourself, there are some reasonably priced options from DealExtrme. (The two first look exactly the same, even if they are different names slapped on top)

My end goal is something like the Gigapanbot, mentioned earlier, so maybe some simple brackets might also do, plus a battery. More about that later.

Here are the items I’ve bought for myself and others so far, followed my wish list, or list of items which might be interesting. The order list can be download in CSV form, while the wish list had to be scraped. For what it’s worth, here is a small Python script which does that, plus a bash script for HTML rendering of image links and product descriptions.

The Python script uses WebDriver / Selenium, and install for that goes:
sudo apt-get install python-pip
sudo easy_install selenium

Orders

Interesting