Page 1

Fix to MicroPython's Memory Allocation Problem on ESP8266

I've been trying to write code that allows me to display text on my ST7735 display. The font module I found is around 4kB of source code that needs to be loaded by Python, compiled into byte code and executed by the Python Virtual Machine, or VM (for more details refers here). This process works somewhat like Java's VM approach, but on devices with limited memory, i.e. the ESP8266, can become troublesome. Loading, compiling and storing the byte code takes up precious memory, which may not always be allocatable; thus throwing an MemoryError: memory allocation failed, allocating XXX bytes.. In this little post I want to show you how you can pre-compile modules for the ESP8266, so you will avoid wasting space. And if that option is too cumbersome for you, I also present a little hack to increase the ESP's heap memory, but that's more of a bodge-job for lazy people: i.e. me :p

Continue Reading →

The end

Infected Linux Mint image

Whoever was one of the unfortunate ones that downloaded an ISO from the Linux Mint website (which is currently offline), may have downloaded a version that was manipulated by someone to sniff out data. Some say that the infected version relays passwords to a Bulgarian IP (heise), others say that the infected distribution comes with a backdoor (zeit). Whatever the issue may be, I wanted to assure that the versions I downloaded were not infected and went out of my way to collect all MD5 hashes I could find.

For those not familiar with MD5, it is a function that produces a seemingly random 128-bit string (commonly displayed as 32 Hex characters) from any given input data. The importance is, that this resulting string can only be generated by the same data. In fact, any modification to the input data (i.e. when it's "hacked") causes the resulting MD5 string to be different. So whenever one downloads a file that comes with a MD5 (also referred to as checksum) you can make sure that the bits haven't been changed. On Mac and Linux, this test is done relatively easily:

md5 <file_name>

So if you want to check whether the Mint ISO you downloaded is infected, check with that against the following official (link) MD5 hashes:

  • 6e7f7e03500747c6c3bfece2c9c8394f : linuxmint-17.3-cinnamon-32bit.iso
  • e71a2aad8b58605e906dbea444dc4983 : linuxmint-17.3-cinnamon-64bit.iso
  • 30fef1aa1134c5f3778c77c4417f7238 : linuxmint-17.3-cinnamon-nocodecs-32bit.iso
  • 3406350a87c201cdca0927b1bc7c2ccd : linuxmint-17.3-cinnamon-nocodecs-64bit.iso
  • df38af96e99726bb0a1ef3e5cd47563d : linuxmint-17.3-cinnamon-oem-64bit.iso

And if you were curious, yes, my 64-bit ISO was actually a hacked version. Maybe that's why it didn't work as seamlessly as the 32-bit distribution 😛


The end

Mint network issues in Parallels

Well, I decided to play around with different Linux distributions. Since I am (as all my friends can vouch for) a massive Apple fanboy, I only install "lesser" operating systems as a VM. That was I can hack and toss around with them and if I break anything, revert back to a snapshot or simply reinstall, without having destroyed my working machine.

So, I tried Ubuntu, which installs and works really easily, but then I came across Mint. It's cleaner and has less bling-bling but works so much nicer (for my liking at least). Yet the one issue I came across when installing it in Parallels was the inability of connecting to the network. Turns out, a simple command refreshes the DHCP status, and because I will forget this crudely simple fix, I decided to make a record of it.

  1. Set the network adapter to "bridged" so that Mint uses the actual hardware and not some emulated stuff
  2. Call the DHCP client for the correct network adapter (in my case eth0):
    dhclient eth0
  3. Done...

And yes: I am very new to Mint, but always happy to learn 😉

The end