Planet Linux Australia

Syndicate content
Planet Linux Australia - http://planet.linux.org.au
Updated: 1 hour 6 min ago

Dave Hall: Wix aren't the Only Ones Violating the GPL

Mon, 2016-10-31 03:02

Recently Matt Mullenweg called out Wix for violating the GPL. Wix's CEO, Avishai Abrahami's post on the company blog missed some of the key issues when it comes to using code licensed under the terms of the GNU General Public License. The GPL doesn't require you to only release the changes made to a dependency. If you use a GPL library in your project, then the entire project is deemed to be a derivate work. This is why the GPL is called a viral license, because if one part of your project is covered by the GPL, then it applies to the entirety of your app. Other people more qualified than me have explained this in more detail, more elegantly than I ever could.

This reminded me of a popular platform that is built on a GPL violation. FlightRadar24 allows users to track flights in real time. FR24's data is collected from multiple sources, including the US FAA and a network of volunteers that run tracking equipment. One of the most common tracking setups uses a Raspberry Pi hooked up to a cheap DVB-T USB tuner. librtlsdr is used to tune the USB stick to the right frequency so it can listen to the tracking signals.

The FlightRadar24 software, FR24Feed, is a single binary that includes a statically linked copy of librtlsdr. On multiple occasions I have asked for a full copy of the source code for the FR24Feed binaries that FlightRadar24 are distributing. They have refused.

FlightRadar are under the mistaken belief that they only have to distribute the source for their modifications to librtlsdr. They have made their patched version of the code available on the FlightRadar24 downloads page. FlightRadar24 say they won't release the source to ensure the quality of their data. I'm sorry, but the GPL doesn't include a clause that excuses you from distributing the source code if you have a bad architecture.

It is disappointing to see FlightRadar24 refusing to comply with the terms of the GPL. I still have everything I need to run a tracking station sitting in a drawer. I'll set up my tracking station once FlightRadar24 release all the full source for FR24Feed.

Stewart Smith: Windows NT4 for PowerPC guest on OPAL on POWER8 in qemu

Sun, 2016-10-30 19:00

Sometimes, programming is just for fun. This is what PREPHV is for Andrei Warkentin. To quote the README:

“This is mostly a huge ugly hack, derived from my
ppc64le_hello code. The running philosophy here is
to throw things together late at night with my family
asleep and see how far I get without a real design
or without a real desire to implement boring things
like IDE (*sigh*) emulation”

Since my day job is maintaining the firmware that it runs on, I decided to have a go (it also ties in with the retro stuff I’ve been blogging about). So…

and I’m off! (yes, this is the very latest qemu and skiboot):

Yes, prephv does clear all thirty two megabytes of guest memory

A quick diversion, if you try Windows NT 3.51 for PowerPC, you get this:

But on NT4, you continue unharmed:

A sign I needed to hack my filesystem of bits of NT installer bits a bit more:

But, on my next try:

Well… looks like there’s an instruction that needs to be emulated (and there’s no code to currently do that). Mind you… this is decently far into booting before we hit anything fatal, which is a pretty impressive effort – and it is tempting to continue and see if it’ll run on real hardware and if it could be made to work well enough to not find any disks :)

Stewart Smith: Failed Retro emulation attempts

Sun, 2016-10-30 17:00

For reasons that should escape everybody, I went back and looked at some old Operating Systems a little while ago: OS/2 Warp, Windows 3.11 and Microsoft Chicago. So, I went on a little adventure this weekend, largely in failure though.

Windows NT 3.51

This was the first version (err… no, second I think) of Windows NT that I ever used.

Lesson 1: qemu doesn’t expose a SCSI adapter that isn’t virtio-scsi (and I have a feeling there aren’t Windows NT 3.51 installer driver floppies for virtio-scsi)

Lesson 2: OMG I’m so glad I don’t have to wait for things to be read off floppy disks anymore:

Lesson 3: I’d forgotten that the Windows directory on NT 3.51 was different to every other Windows NT version, being \WINNT35

Lesson 3: Yeah, sometimes there’s just fail.

Windows NT 4.0

This brought the UI of Windows 95 to Windows NT. It was a thing. It required a fairly beefy PC for the day, but it could use two CPUs if you were that amazingly rich (dual Pentium Pro was a thing)

Lesson 1: Windows NT 4 does not like 8GB disks. My idea of “creating a small disk for a VM for an old OS as it probably won’t work well with a 20GB disk” needs to be adjusted. I’m writing this on a system with 8 times more RAM than what I ended up using for a disk for Windows NT 4.

But hey, back to \WINNT rather than \WINNT35 or \WINDOWS

Lesson 2: Sometimes, full system emulation turns out to be a better idea:

Lesson 3: Remember when Windows couldn’t actually format NTFS in the installer and it installed to FAT and then converted to NTFS? No? Well, aren’t you lucky.

Apple Rhapsody DR2

Before there was MacOS X, there was a project called Rhapsody. This was to take NeXTStep (from NeXT, which Apple bought to get both NeXTStep and Steve Jobs as every internal “let’s replace the aging MacOS” project had utterly failed for the past ten years). Rhapsody was not going to be backwards compatible until everybody said that was a terrible idea and the Blue Box was added (known as Classic) – basically, a para-virtualized VM running the old MacOS 9.

Anyway, for the first two developer releases, it was also available on x86 (not just PowerPC). This was probably because a PowerPC port to Macs was a lot newer than the x86 port.

So, I dusted off the (virtual) Boot and Driver floppies and fired up qemu…..

Yeah, MacOS X got a better installer…

Hopeful!

This was after I decided that using KVM was a bad Idea:

Nope… and this is where we stop. There seems to be some issue with ATA drivers? I honestly can’t be bothered to debug it (although… for the PowerPC version… maybe).

MacOS 9.2

Well.. this goes a lot better now thanks to a whole bunch of patches hitting upstream Qemu recently (thanks Ben!)

Yeah, I was kind of tempted to set up Outlook Express to read my email…. But running MacOS 9 was way too successful, so I had to stop there :)

Chris Smart: Building and Booting Upstream Linux and U-Boot for Raspberry Pi 2/3 ARM Boards

Thu, 2016-10-27 23:03

My home automation setup will make use of Arduinos and also embedded Linux devices. I’m currently looking into a few boards to see if any meet my criteria. Previously I looked at the Orange Pi One, now I’m looking at the Raspberry Pi 2 (which is compatible with the 3).

The most important factor for me is that the device must be supported in upstream Linux (preferably stable, but mainline will do) and U-Boot. I do not wish to use any old, crappy, vulnerable vendor trees!

The Raspberry Pi needs little introduction. It’s a small ARM device, created for education, that’s taken the world by storm and is used in lots of projects.

Raspberry Pi 2, powered by USB with 3v UART connected

The Raspberry Pi actually has native support for booting a kernel, you don’t have to use U-Boot. However, one of the neat things about U-Boot is that it can provide netboot capabilities, so that you can boot your device from images across the network (we’re just going to use it to boot a kernel and initramfs, however).

One of the other interesting things about the Raspberry Pi is that there are lots of ways to tweak the device using a config.txt file.

The Raspberry Pi 3 has a 64bit CPU, however it is probably best run in 32bit mode (as a Raspberry Pi 2) as 64bit userland is not particularly advanced in ARM world, yet.

Fedora 25 will finally support Raspberry Pi 2 and 3 (although not all peripherals will be supported right away).

Connecting UART

The UART on the Raspberry Pi uses the GND, TX and RX connections which are on the GPIO pins (see above). Plug the corresponding cables from a 3.3V UART cable onto these pins and then into a USB port on your machine.

Your device will probably be /dev/ttyUSB0, but you can check this with dmesg just after plugging it in.

Now we can simply use screen to connect to the UART, but you’ll have to be in the dialout group.

sudo gpasswd -a ${USER} dialout
newgrp dialout
screen /dev/ttyUSB0 115200

Note that you won’t see anything just yet without an SD card that has a working bootloader. We’ll get to that shortly!

Partition the SD card

First things first, get yourself an SD card.

The card needs to have an msdos partition table with a smallish boot partition (formatted FAT32). The binary U-Boot file will sit there, called kernel.img, along with some other bootloader files. You can use the rest of the card for the root file system (but we’ll boot an initramfs, so it’s not needed).

Assuming your card is at /dev/sdx (replace as necessary, check dmesg after plugging it in if you’re not sure).

sudo umount /dev/sdx* # makes sure it's not mounted
sudo parted -s /dev/sdx \
mklabel msdos \
mkpart primary fat32 1M 30M \
mkpart primary ext4 30M 100%

Now we can format the partitions (upstream U-Boot supports ext3 on the boot partition).
sudo mkfs.vfat /dev/sdx1
sudo mkfs.ext4 /dev/sdx2

Next, mount the boot partition to /mnt, this is where we will copy everything to.
sudo mount /dev/sdx1 /mnt

Leave your SD card plugged in, we will need to copy the bootloader to it soon!

Upstream U-Boot Bootloader

Install the arm build toolchain dependencies.

sudo dnf install \
gcc-arm-linux-gnu \
binutils-arm-linux-gnu \
uboot-tools

We need to clone upstream U-Boot Git tree. Note that I’m checking out the release directly (-b v2016.09.01) but you could leave this off to get master, or change it to a different tag if you want.
cd "${HOME}"
git clone --depth 1 -b v2016.09.01 git://git.denx.de/u-boot.git
cd u-boot

There are default configs for both Raspberry Pi 2 and 3, so select the one you want.
# Run this for the Pi 2
CROSS_COMPILE=arm-linux-gnu- make rpi_2_defconfig
# Run this for the Pi 3
CROSS_COMPILE=arm-linux-gnu- make rpi_3_32b_defconfig

Now, compile it.
CROSS_COMPILE=arm-linux-gnu- make -j$(nproc)

Now, copy the u-boot.bin file onto the SD card, and call it kernel.img (this is what the bootloader looks for).

sudo cp -iv u-boot.bin /mnt/kernel.img

Proprietary bootloader files

Sadly, the Raspberry Pi cannot boot entirely on open source software, we need to get the proprietary files from Broadcom and place them on the SD card also.

Clone the Raspberry Pi Foundation’s GitHub repository.
cd "${HOME}"
git clone --depth 1 https://github.com/raspberrypi/firmware

Copy the minimum set of required files to the SD card.
sudo cp -iv firmware/boot/{bootcode.bin,fixup.dat,start.elf} /mnt/

Finally, unmount the SD card.
sync && sudo umount /mnt

OK, now our bootloader should be ready to go.

Testing our bootloader

Now we can remove the SD card from the computer and plug it into the powered off Raspberry Pi to see if our bootloader build was successful.

Switch back to your terminal that’s running screen and then power up the Pi. Note that the device will try to netboot by default, so you’ll need to hit the enter key when you see a line that says the following.

(Or you can just repeatedly hit enter key in the screen console while you turn the device on.)

Note that if you don’t see anything, swap the RX and TX pins on the UART and try again.

With any luck you will then get to a U-Boot prompt where we can check the build by running the version command. It should have the U-Boot version we checked out from Git and today’s build date!

Raspberry Pi running U-Boot

Hurrah! If that didn’t work for you, repeat the build and writing steps above. You must have a working bootloader before you can get a kernel to work.

If that worked, power off your device and re-insert the SD card into your computer and mount it at /mnt.

sudo umount /dev/sdx* # unmount everywhere first
sudo mount /dev/sdx1 /mnt

Creating an initramfs

Of course, a kernel won’t be much good without some userspace. Let’s use Fedora’s static busybox package to build a simple initramfs that we can boot on the Raspberry Pi.

I have a script that makes this easy, you can grab it from GitHub.

Ensure your SD card is plugged into your computer and mounted at /mnt, then we can copy the file on!

cd ${HOME}
git clone https://github.com/csmart/custom-initramfs.git
cd custom-initramfs
./create_initramfs.sh --arch arm --dir "${PWD}" --tty ttyAMA0

This will create an initramfs for us in your custom-initramfs directory, called initramfs-arm.cpio.gz. We’re not done yet, though, we need to convert this to the format supported by U-Boot (we’ll write it directly to the SD card).

gunzip initramfs-arm.cpio.gz
sudo mkimage -A arm -T ramdisk -C none -n uInitrd \
-d initramfs-arm.cpio /mnt/uInitrd

Now we have a simple initramfs ready to go.

Upstream Linux Kernel

Clone the mainline Linux tree (this will take a while). Note that I’m getting the latest tagged release by default (-b v4.9-rc1) but you could leave this off or change it to some other tag if you want.

cd ${HOME}
git clone --depth 1 -b v4.9-rc1 \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Or, if you want to try linux-stable, clone this repo instead.
git clone --depth 1 -b v4.8.4 \
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux

Now go into the linux directory.
cd linux

Building the kernel

Now we are ready to build our kernel!

Load the default kernel config for the sunxi boards.
ARCH=arm CROSS_COMPILE=arm-linux-gnu- make bcm2835_defconfig

If you want, you could modify the kernel config here, but it’s not necessary.
ARCH=arm CROSS_COMPILE=arm-linux-gnu- make menuconfig

Build the kernel image and device tree blob.
ARCH=arm CROSS_COMPILE=arm-linux-gnu- make -j$(nproc) zImage dtbs

Mount the boot partition and copy on the kernel and device tree file.
sudo cp -iv arch/arm/boot/zImage /mnt/
sudo cp -iv arch/arm/boot/dts/bcm2836-rpi-2-b.dtb /mnt/

Bootloader config

Next we need to make a bootloader file, boot.cmd, which tells U-Boot what to load and boot (the kernel, device tree and initramfs).

The bootargs line says to output the console to serial and to boot from the ramdisk. Variables are used for the memory locations of the kernel, dtb and initramfs.

Note that the root device is /dev/root which is required for the initramfs.

cat > boot.cmd << EOF
fatload mmc 0 \${kernel_addr_r} zImage
fatload mmc 0 \${fdt_addr_r} bcm2836-rpi-2-b.dtb
fatload mmc 0 \${ramdisk_addr_r} uInitrd
setenv bootargs console=ttyAMA0,115200 earlyprintk root=/dev/root \
rootwait panic=10
bootz \${kernel_addr_r} \${ramdisk_addr_r} \${fdt_addr_r}
EOF

Compile the bootloader file and output it directly to the SD card at /mnt.
sudo mkimage -C none -A arm -T script -d boot.cmd /mnt/boot.scr

Now, unmount your SD card.

sudo umount /dev/sdx*

Testing it all

Insert it into the Raspberry Pi and turn it on! Hopefully you’ll see it booting the kernel on your screen terminal window.

You should be greeted by a login prompt. Log in with root (no password).

Login prompt

That’s it! You’ve built your own Linux system for the Raspberry Pi!

Networking

Log in as root and give the Ethernet device (eth0) an IP address on your network.

Now test it with a tool, like ping, and see if your network is working.

Here’s an example:

Networking on Raspberry Pi

Memory usage

There is clearly lots more you can do with this device…

Raspberry Pi Memory Usage

Enjoy!

Maxim Zakharov: dpsearch-4.54-2016-10-26

Wed, 2016-10-26 11:27

A new snapshot version of DataparkSearch Engine has been released. You can get it on Google Drive or on GitHub.

Changes made since previous one:

  • Corrected SQL schema for MySQL5
  • Fixed crash on URLs with no schema specified
  • New detection for Apache version
  • Fixed crossword section construction
  • p, option and input HTML tags can now be a section
  • More fine sleeping on mutex lock failure
  • Fixed compilation on FreeBSD 10
  • Added 'Robots collect' command
  • Fixed crash if dt:minute limit specified
  • Do not process sitemaps for Server/Realm/Subnet commands with nofollow option specified
  • Some other minor fixes

I am planning to retire the support for Apache 1.3 in future. Let me know if your are still using it.

Francois Marier: Tweaking Referrers For Privacy in Firefox

Mon, 2016-10-24 11:01

The Referer header has been a part of the web for a long time. Websites rely on it for a few different purposes (e.g. analytics, ads, CSRF protection) but it can be quite problematic from a privacy perspective.

Thankfully, there are now tools in Firefox to help users and developers mitigate some of these problems.

Description

In a nutshell, the browser adds a Referer header to all outgoing HTTP requests, revealing to the server on the other end the URL of the page you were on when you placed the request. For example, it tells the server where you were when you followed a link to that site, or what page you were on when you requested an image or a script. There are, however, a few limitations to this simplified explanation.

First of all, by default, browsers won't send a referrer if you place a request from an HTTPS page to an HTTP page. This would reveal potentially confidential information (such as the URL path and query string which could contain session tokens or other secret identifiers) from a secure page over an insecure HTTP channel. Firefox will however include a Referer header in HTTPS to HTTPS transitions unless network.http.sendSecureXSiteReferrer (removed in Firefox 52) is set to false in about:config.

Secondly, using the new Referrer Policy specification web developers can override the default behaviour for their pages, including on a per-element basis. This can be used both to increase or reduce the amount of information present in the referrer.

Legitimate Uses

Because the Referer header has been around for so long, a number of techniques rely on it.

Armed with the Referer information, analytics tools can figure out:

  • where website traffic comes from, and
  • how users are navigating the site.

Another place where the Referer is useful is as a mitigation against cross-site request forgeries. In that case, a website receiving a form submission can reject that form submission if the request originated from a different website.

It's worth pointing out that this CSRF mitigation might be better implemented via a separate header that could be restricted to particularly dangerous requests (i.e. POST and DELETE requests) and only include the information required for that security check (i.e. the origin).

Problems with the Referrer

Unfortunately, this header also creates significant privacy and security concerns.

The most obvious one is that it leaks part of your browsing history to sites you visit as well as all of the resources they pull in (e.g. ads and third-party scripts). It can be quite complicated to fix these leaks in a cross-browser way.

These leaks can also lead to exposing private personally-identifiable information when they are part of the query string. One of the most high-profile example is the accidental leakage of user searches by healthcare.gov.

Solutions for Firefox Users

While web developers can use the new mechanisms exposed through the Referrer Policy, Firefox users can also take steps to limit the amount of information they send to websites, advertisers and trackers.

In addition to enabling Firefox's built-in tracking protection by setting privacy.trackingprotection.enabled to true in about:config, which will prevent all network connections to known trackers, users can control when the Referer header is sent by setting network.http.sendRefererHeader to:

  • 0 to never send the header
  • 1 to send the header only when clicking on links and similar elements
  • 2 (default) to send the header on all requests (e.g. images, links, etc.)

It's also possible to put a limit on the maximum amount of information that the header will contain by setting the network.http.referer.trimmingPolicy to:

  • 0 (default) to send the full URL
  • 1 to send the URL without its query string
  • 2 to only send the scheme, host and port

or using the network.http.referer.XOriginTrimmingPolicy option (added in Firefox 52) to only restrict the contents of referrers attached to cross-origin requests.

Site owners can opt to share less information with other sites, but they can't share any more than what the user trimming policies allow.

Another approach is to disable the Referer when doing cross-origin requests (from one site to another). The network.http.referer.XOriginPolicy preference can be set to:

  • 0 (default) to send the referrer in all cases
  • 1 to send a referrer only when the base domains are the same
  • 2 to send a referrer only when the full hostnames match
Breakage

If you try to remove all referrers (i.e. network.http.sendRefererHeader = 0, you will most likely run into problems on a number of sites, for example:

The first two have been worked-around successfully by setting network.http.referer.spoofSource to true, an advanced setting which always sends the destination URL as the referrer, thereby not leaking anything about the original page.

Unfortunately, the last two are examples of the kind of breakage that can only be fixed through a whitelist (an approach supported by the smart referer add-on) or by temporarily using a different browser profile.

My Recommended Settings

As with my cookie recommendations, I recommend strengthening your referrer settings but not disabling (or spoofing) it entirely.

While spoofing does solve many the breakage problems mentioned above, it also effectively disables the anti-CSRF protections that some sites may rely on and that have tangible user benefits. A better approach is to limit the amount of information that leaks through cross-origin requests.

If you are willing to live with some amount of breakage, you can simply restrict referrers to the same site by setting:

network.http.referer.XOriginPolicy = 2

or to sites which belong to the same organization (i.e. same ETLD/public suffix) using:

network.http.referer.XOriginPolicy = 1

This prevent leaks to third-parties while giving websites all of the information that they can already see in their own server logs.

On the other hand, if you prefer a weaker but more compatible solution, you can trim cross-origin referrers down to just the scheme, hostname and port:

network.http.referer.XOriginTrimmingPolicy = 2

I have not yet found user-visible breakage using this last configuration. Let me know if you find any!

Tridge on UAVs: APM:Plane 3.7.1 released and 3.8.0 beta nearly ready for testing

Sun, 2016-10-23 21:03

New plane releases from ArduPilot.org:

Development is really hotting up for fixed wing and quadplanes! I've just released 3.7.1 and I plan on releasing the first beta of the major 3.8.0 release in the next week.
The 3.7.1 release fixes some significant bugs reported by users since the 3.7.0 release. Many thanks for all the great feedback on the release from users!
The 3.8.0 release includes a lot more new stuff, including a new servo mapping backend and a new persistent auto-trim system that is makes getting the servo trim just right a breeze.
Happy flying!

Chris Smart: Building and Booting Upstream Linux and U-Boot for Orange Pi One ARM Board (with Ethernet)

Sun, 2016-10-23 17:03

My home automation setup will make use of Arduinos and also embedded Linux devices. I’m currently looking into a few boards to see if any meet my criteria.

The most important factor for me is that the device must be supported in upstream Linux (preferably stable, but mainline will do) and U-Boot. I do not wish to use any old, crappy, vulnerable vendor trees!

The Orange Pi One is a small, cheap ARM board based on the AllWinner H3 (sun8iw7p1) SOC with a quad-Core Cortex-A7 ARM CPU and 512MB RAM. It has no wifi, but does have an onboard 10/100 Ethernet provided by the SOC (Linux patches incoming). It has no NAND flash (not supported upstream yet anyway), but does support SD. There is lots of information available at http://linux-sunxi.org.

Orange Pi One

Note that while Fedora 25 does not yet support this board specifically it does support both the Orange Pi PC (which is effectively a more full-featured version of this device) and the Orange Pi Lite (which is the same but swaps Ethernet for WiFi). Using either of those configurations should at least boot on the Orange Pi One.

Connecting UART

The UART on the Pi One uses the GND, TX and RX connections which are next to the Ethernet jack. Plug the corresponding cables from a 3.3V UART cable onto these pins and then into a USB port on your machine.

UART Pin Connections (RX yellow, TX orange, GND black)

Your device will probably be /dev/ttyUSB0, but you can check this with dmesg just after plugging it in.

Now we can simply use screen to connect to the UART, but you’ll have to be in the dialout group.

sudo gpasswd -a ${USER} dialout
newgrp dialout
screen /dev/ttyUSB0 115200

Note that you won’t see anything just yet without an SD card that has a working bootloader. We’ll get to that shortly!

Partition the SD card

First things first, get yourself an SD card.

While U-Boot itself is embedded in the card and doesn’t need it to be partitioned, it will be required later to read the boot files.

U-Boot needs the card to have an msdos partition table with a small boot partition (ext now supported) that starts at 1MB. You can use the rest of the card for the root file system (but we’ll boot an initramfs, so it’s not needed).

Assuming your card is at /dev/sdx (replace as necessary, check dmesg after plugging it in if you’re not sure).

sudo umount /dev/sdx* # makes sure it's not mounted
sudo parted -s /dev/sdx \
mklabel msdos mkpart \
primary ext3 1M 10M \
mkpart primary ext4 10M 100%

Now we can format the partitions (upstream U-Boot supports ext3 on the boot partition).
sudo mkfs.ext3 /dev/sdx1
sudo mkfs.ext4 /dev/sdx2

Leave your SD card plugged in, we will need to write the bootloader to it soon!

Upstream U-Boot Bootloader

Install the arm build toolchain dependencies.

sudo dnf install \
gcc-arm-linux-gnu \
binutils-arm-linux-gnu \
uboot-tools

We need to clone upstream U-Boot Git tree. Note that I’m checking out the release directly (-b v2016.09.01) but you could leave this off to get master, or change it to a different tag if you want.
cd ${HOME}
git clone --depth 1 -b v2016.09.01 git://git.denx.de/u-boot.git
cd u-boot

There is a defconfig already for this board, so simply make this and build the bootloader binary.
CROSS_COMPILE=arm-linux-gnu- make orangepi_one_defconfig
CROSS_COMPILE=arm-linux-gnu- make -j$(nproc)

Write the bootloader to the SD card (replace /dev/sdx, like before).
sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=1024 seek=8

Wait until your device has stopped writing (if you have an LED you can see this) or run sync command before ejecting.

Testing our bootloader

Now we can remove the SD card and plug it into the powered off Orange Pi One to see if our bootloader build was successful.

Switch back to your terminal that’s running screen and then power up the Orange Pi One. Note that the device will try to netboot by default, so you’ll need to hit the enter key when you see a line that says the following.

(Or you can just repeatedly hit enter key in the screen console while you turn the device on.)

Note that if you don’t see anything, swap the RX and TX pins on the UART and try again.

With any luck you will then get to a U-Boot prompt where we can check the build by running the version command. It should have the U-Boot version we checked out from Git and today’s build date!

U-Boot version

Hurrah! If that didn’t work for you, repeat the build and writing steps above. You must have a working bootloader before you can get a kernel to work.

If that worked, power off your device and re-insert the SD card into your computer and mount it at /mnt.

sudo umount /dev/sdx* # unmount everywhere first
sudo mount /dev/sdx1 /mnt

Creating an initramfs

Of course, a kernel won’t be much good without some userspace. Let’s use Fedora’s static busybox package to build a simple initramfs that we can boot on the Orange Pi One.

I have a script that makes this easy, you can grab it from GitHub.

Ensure your SD card is plugged into your computer and mounted at /mnt, then we can copy the file on!

cd ${HOME}
git clone https://github.com/csmart/custom-initramfs.git
cd custom-initramfs
./create_initramfs.sh --arch arm --dir "${PWD}" --tty ttyS0

This will create an initramfs for us in your custom-initramfs directory, called initramfs-arm.cpio.gz. We’re not done yet, though, we need to convert this to the format supported by U-Boot (we’ll write it directly to the SD card).

gunzip initramfs-arm.cpio.gz
sudo mkimage -A arm -T ramdisk -C none -n uInitrd \
-d initramfs-arm.cpio /mnt/uInitrd

Now we have a simple initramfs ready to go.

Upstream Linux Kernel

The Ethernet driver has been submitted to the arm-linux mailing list (it’s up to its 4th iteration) and will hopefully land in 4.10 (it’s too late for 4.9 with RC1 already out).

Clone the mainline Linux tree (this will take a while). Note that I’m getting the latest tagged release by default (-b v4.9-rc1) but you could leave this off or change it to some other tag if you want.

cd ${HOME}
git clone --depth 1 -b v4.9-rc1 \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Or, if you want to try linux-stable, clone this repo instead.
git clone --depth 1 -b v4.8.4 \
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux

Now go into the linux directory.
cd linux

Patching in EMAC support for SOC

If you don’t need the onboard Ethernet, you can skip this step.

We can get the patches from the Linux kernel’s Patchwork instance, just make sure you’re in the directory for your Linux Git repository.

Note that these will probably only apply cleanly on top of mainline v4.9 Linux tree, not stable v4.8.

# [v4,01/10] ethernet: add sun8i-emac driver
wget https://patchwork.kernel.org/patch/9365783/raw/ \
-O sun8i-emac-patch-1.patch
 
# [v4,04/10] ARM: dts: sun8i-h3: Add dt node for the syscon
wget https://patchwork.kernel.org/patch/9365773/raw/ \
-O sun8i-emac-patch-4.patch
 
# [v4,05/10] ARM: dts: sun8i-h3: add sun8i-emac ethernet driver
wget https://patchwork.kernel.org/patch/9365757/raw/ \
-O sun8i-emac-patch-5.patch
 
# [v4,07/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange PI One
wget https://patchwork.kernel.org/patch/9365767/raw/ \
-O sun8i-emac-patch-7.patch
 
# [v4,09/10] ARM: sunxi: Enable sun8i-emac driver on sunxi_defconfig
wget https://patchwork.kernel.org/patch/9365779/raw/ \
-O sun8i-emac-patch-9.patch

We will apply these patches (you could also use git apply, or grab the mbox if you want and use git am).

for patch in 1 4 5 7 9 ; do
    patch -p1 < sun8i-emac-patch-${patch}.patch
done

Hopefully that will apply cleanly.

Building the kernel

Now we are ready to build our kernel!

Load the default kernel config for the sunxi boards.
ARCH=arm CROSS_COMPILE=arm-linux-gnu- make sunxi_defconfig

If you want, you could modify the kernel config here, for example remove support for other AllWinner SOCs.
ARCH=arm CROSS_COMPILE=arm-linux-gnu- make menuconfig

Build the kernel image and device tree blob.
ARCH=arm CROSS_COMPILE=arm-linux-gnu- make -j$(nproc) zImage dtbs

Mount the boot partition and copy on the kernel and device tree file.
sudo cp arch/arm/boot/zImage /mnt/
sudo cp arch/arm/boot/dts/sun8i-h3-orangepi-one.dtb /mnt/

Bootloader config

Next we need to make a bootloader file, boot.cmd, which tells U-Boot what to load and boot (the kernel, device tree and initramfs).

The bootargs line says to output the console to serial and to boot from the ramdisk. Variables are used for the memory locations of the kernel, dtb and initramfs.

Note that the root device is /dev/root which is required for the initramfs.

cat > boot.cmd << EOF
ext2load mmc 0 \${kernel_addr_r} zImage
ext2load mmc 0 \${fdt_addr_r} sun8i-h3-orangepi-one.dtb
ext2load mmc 0 \${ramdisk_addr_r} uInitrd
setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/root \
rootwait panic=10
bootz \${kernel_addr_r} \${ramdisk_addr_r} \${fdt_addr_r}
EOF

Compile the bootloader file and output it directly to the SD card at /mnt.
sudo mkimage -C none -A arm -T script -d boot.cmd /mnt/boot.scr

Now, unmount your SD card.

sudo umount /dev/sdx*

Testing it all

Insert it into the Orange Pi One and turn it on! Hopefully you’ll see it booting the kernel on your screen terminal window.

You should be greeted by a login prompt. Log in with root (no password).

Login prompt

That’s it! You’ve built your own Linux system for the Orange Pi One!

Networking

Log in as root and give the Ethernet device (eth0) an IP address on your network.

Now test it with a tool, like ping, and see if your network is working.

Here’s an example:

Networking on Orange Pi One

Memory usage

There is clearly lots more you can do with this device…

Memory usage

Enjoy!

Chris Smart: My Custom Open Source Home Automation Project – Part 3, Roll Out

Sat, 2016-10-22 19:03

In Part 1 I discussed motivation and research where I decided to build a custom, open source wired solution. Part 2 discussed the prototype and other experiments.

Because we were having to fit in with the builder, I didn’t have enough time to finalise the smart system, so I needed a dumb mode. This Part 3 is about rolling out dumb mode in Smart house!

Operation “dumb mode, Smart house” begins

We had a proven prototype, now we had to translate that into a house-wide implementation.

First we designed and mapped out the cabling.

Cabling Plans

Cable ALL THE THINGS.

  • Cat5e (sometimes multiple runs) for room Arduinos
  • Cat5e to windows for future curtain motors
  • Reed switch cables to light switch
  • Regular Cat6 data cabling too, of course!
  • Whatever else we thought we might need down the track

Time was tight (fitting in with the builder) but we got there (mostly).

  • Ran almost 2 km of cable in total
  • This was a LOT of work and took a LOT of time

Cabling

Cabled Wall Plates

Cabled Wireless Access Point

Cable Run

Electrical cable

This is the electrician’s job.

  • Electrician ran each bank of lights on their own circuit
  • Multiple additional electrical circuits
    • HA on its own electrical circuit, UPS backed
    • Study/computers on own circuit, UPS backed
    • Various others like dryer, ironing board, entertainment unit, alarm, ceiling fans, ovens, etc
  • Can leave the house and turn everything off
    (except essentials)
Relays

The relays had to be reliable, but also available off-the-shelf as I didn’t want to get something that’s custom or hard to replace. Again, for devices that draw too much current for the relay, it will throw a contactor instead so that the device can still be controlled.

  • Went with Finder 39 series relays, specifically 39.31.0.024.0060
  • Very thin profile
  • Built in fuses
  • Common bus bars
  • Single Pole Double Throw (SPDT)

Finder Relays with Din Mount Module

These are triggered by 24V DC which switches the 240V AC for the circuit. The light switches are running 24V and when you press the button it completes the circuit, providing 24V input to the relay (which turns on the 240V and therefore the light).

There are newer relays now which have an input range (e.g. 0-24V), I would probably use those instead if I was doing it again today so that it can be more easily fired from an array of outputs (not just a 24V relay driver shield).

The fact that they are SPDT means that I can set the relay to be normally open (NO) in which case the relay is off by default, or normally closed (NC) in which case the relay is on by default. This means that if the smart system goes down and can’t provide voltage to the input side of the relay, certain banks of lights (such as the hallway, stairs, kitchen, bathroom and garage lights) will turn on (so that the house is safe while I fix it).

Bank of Relays

In the photo above you can see the Cat5e 24V lines from the light switch circuits coming into the grey terminal block at the bottom. They are then cabled to the input side of the relays. This means that we don’t touch any AC and I can easily change what’s providing the input to the relay (to a relay board on an Arduino, for example).

Rack (excuse the messy data cabling)

There are two racks, one upstairs and one downstairs, that provide the infrastructure for the HA and data networks.

PSU running at 24V

Each rack has a power supply unit (PSU) running at 24V which provides the power for the light switches in dumb mode. These are running in parallel to provide redundancy for the dumb network in case one dies.

You can see that there is very little voltage drop.

Relay Timers

The Finder relays also support timer modules, which is very handy for something that you want to automatically turn off after a certain (configurable) amount of time.

  • Heated towel racks are bell press switches
  • Uses a timer relay to auto turn off
  • Modes and delay configurable via dip switches on relay
UPS backed GPO Circuits

UPS in-lined GPO Circuits

Two GPO circuits are backed by UPS which I can simply plug in-line and feed back to the circuit. These are the HA network as well as the computer network. If the power is cut to the house, my HA will still have power (for a while) and the Internet connection will remain up.

Clearly I’ll have no lights if the power is cut, but I could power some emergency LED lighting strips from the UPS lines – that hasn’t been done yet though.

Switches

The switches for dumb mode are regular also off the shelf light switches.

  • Playing with light switches (yay DC!)
  • Cabling up the switches using standard Clipsal gear
  • Single Cat5e cable can power up to 4 switches
  • Support one, two, three and four way switches
  • Bedroom switches use switch with LED (can see where the switch is at night)

Bathroom Light Switch (Dumb Mode)

We have up to 4-way switches so you can turn a single light on or off from 4 locations. The entrance light is wired up this way, you can control it from:

  • Front door
  • Hallway near internal garage door
  • Bottom of the stairs
  • Top of the stairs

A single Cat5e cable can run up to 4 switches.

Cat5e Cabling for Light Switch

  • Blue and orange +ve
  • White-blue and white-orange -ve
  • Green switch 1
  • White-green switch 2
  • Brown switch 3
  • White-brown switch 4

Note that we’re using two wires together for +ve and -ve which helps increase capacity and reduce voltage drop (followed the Clipsal standard wiring of blue and orange pairs).

Later in Smart Mode, this Cat5e cable will be re-purposed as Ethernet for an Arduino or embedded Linux device.

Hallway Passive Infrared (PIR) Motion Sensors

I wanted the lights in the hallway to automatically turn on at night if someone was walking to the bathroom or what not.

  • Upstairs hallway uses two 24V PIRs in parallel
  • Either one turns on lights
  • Connected to dumb mode network so fire relay as everything else
  • Can be overridden by switch on the wall
  • Adjustable for sensitivity, light level and length of time

Hallway PIRs

Tunable settings for PIR

Tweaking the PIR means I have it only turning on the lights at night.

Dumb mode results

We have been using dumb mode for over a year now, it has never skipped a beat.

Now I just need to find the time to start working on the Smart Mode…

Chris Smart: My Custom Open Source Home Automation Project – Part 2, Design and Prototype

Sat, 2016-10-22 19:03

In Part 1 I discussed motivation and research where I decided to build a custom, open source wired solution. In this Part 2 I discuss the design and the prototype that proved the design.

Wired Design

Although there are options like 1-Wire, I decided that I wanted more flexibility at the light switches.

  • Inspired by Jon Oxer’s awesome SuperHouse.tv
  • Individual circuits for lights and some General Purpose Outlets (GPO)
  • Bank of relays control the circuits
  • Arduinos and/or embedded Linux devices control the relays

How would it work?

  • One Arduino or embedded Linux device per room
  • Run C-Bus Cat5e cable to light switches to power Arduino, provide access to HA network
  • Room Arduino takes buttons (lights, fans, etc) and sensors (temp, humidity, reed switch, PIR, etc) as inputs
  • Room Arduino sends network message to relay Arduino
  • Arduino with relay shield fires relay to enable/disable power to device (such as a light, fan, etc)

Basic design

Of course this doesn’t just control lights, but also towel racks, fans, etc. Running C-Bus cable means that I can more easily switch to their proprietary system if I fail (or perhaps sell the house).

A relay is fine for devices such as LED downlights which don’t draw much current, but for larger devices (such as ovens and airconditioning) I will use the relay to throw a contactor.

Network Messaging

For the network messaging I chose MQTT (as many others have).

  • Lightweight
  • Supports encryption
  • Uses publish/subscribe model with a broker
  • Very easy to set up and well supported by Arduino and Linux

The way it works would be for the relay driver to subscribe to topics from devices around the house. Those devices publish messages to the topic, such as when buttons are pressed or sensors are triggered. The relay driver parses the messages and reacts accordingly (turning a device on or off).

Cabling Benefits
  • More secure than wireless
  • More future proof
  • DC only, no need to touch AC
  • Provides PoE for devices and motors
  • Can still use wireless (e.g. ZigBee) if I want to
  • Convert to proprietary system (C-Bus) if I fail
  • My brother is a certified cabler

Chris Smart: My Custom Open Source Home Automation Project – Part 1, Motivation and Research

Sat, 2016-10-22 19:03

In January 2016 I gave a presentation at the Canberra Linux Users Group about my journey developing my own Open Source home automation system. This is an adaptation of that presentation for my blog. Big thanks to my brother, Tim, for all his help with this project!

Comments and feedback welcome.

Why home automation?
  • It’s cool
  • Good way to learn something new
  • Leverage modern technology to make things easier in the home

At the same time, it’s kinda scary. There is a lack of standards and lack of decent security applied to most Internet of Things (IoT) solutions.

Motivation and opportunity
  • Building a new house
  • Chance to do things more easily at frame stage while there are no walls

Frame stage

Some things that I want to do with HA
  • Respond to the environment and people in the home
  • Alert me when there’s a problem (fridge left open, oven left on!)
  • Gather information about the home, e.g.
    • Temperature, humidity, CO2, light level
    • Open doors and windows and whether the house is locked
    • Electricity usage
  • Manage lighting automatically, switches, PIR, mood, sunset, etc
  • Control power circuits
  • Manage access to the house via pin pad, proxy card, voice activation, retina scans
  • Control gadgets, door bell/intercom, hot water, AC heating/cooling, exhaust fans, blinds and curtains, garage door
  • Automate security system
  • Integrate media around the house (movie starts, dim the lights!)
  • Water my garden, and more..
My requirements for HA
  • Open
  • Secure
  • Extensible
  • Prefer DC only, not AC
  • High Wife Acceptance Factor (important!)

There’s no existing open source IoT framework that I could simply install, sit back and enjoy. Where’s the fun in that, anyway?

Research time!

Three main options:

  • Wireless
  • Wired
  • Combination of both
Wireless Solutions
  • Dominated by proprietary Z-Wave (although has since become more open)
  • Although open standards based also exist, like ZigBee and 6LoWPAN

Z-Wave modules

Wireless Pros

  • Lots of different gadgets available
  • Gadgets are pretty cheap and easy to find
  • Easy to get up and running
  • Widely supported by all kinds of systems

Wireless Cons

  • Wireless gadgets are pretty cheap and nasty
  • Most are not open
  • Often not updateable, potentially insecure
  • Connect to AC
  • Replace or install a unit requires an electrician
  • Often talk to the “cloud”

So yeah, I could whack those up around my house, install a bridge and move on with my life, but…

  • Not as much fun!
  • Don’t want to rely on wireless
  • Don’t want to rely on an electrician
  • Don’t really want to touch AC
  • Cheap gadgets that are never updated
  • Security vulnerabilities makes it high risk

Wired Solutions

  • Proprietary systems like Clipsal’s C-Bus
  • Open standards based systems like KNX
  • Custom hardware
  • Expensive

Russell Coker: Another Broken Nexus 5

Sat, 2016-10-22 17:02

In late 2013 I bought a Nexus 5 for my wife [1]. It’s a good phone and I generally have no complaints about the way it works. In the middle of 2016 I had to make a warranty claim when the original Nexus 5 stopped working [2]. Google’s warranty support was ok, the call-back was good but unfortunately there was some confusion which delayed replacement.

Once the confusion about the IMEI was resolved the warranty replacement method was to bill my credit card for a replacement phone and reverse the charge if/when they got the original phone back and found it to have a defect covered by warranty. This policy meant that I got a new phone sooner as they didn’t need to get the old phone first. This is a huge benefit for defects that don’t make the phone unusable as you will never be without a phone. Also if the user determines that the breakage was their fault they can just refrain from sending in the old phone.

Today my wife’s latest Nexus 5 developed a problem. It turned itself off and went into a reboot loop when connected to the charger. Also one of the clips on the rear case had popped out and other clips popped out when I pushed it back in. It appears (without opening the phone) that the battery may have grown larger (which is a common symptom of battery related problems). The phone is slightly less than 3 years old, so if I had got the extended warranty then I would have got a replacement.

Now I’m about to buy a Nexus 6P (because the Pixel is ridiculously expensive) which is $700 including postage. Kogan offers me a 3 year warranty for an extra $108. Obviously in retrospect spending an extra $100 would have been a benefit for the Nexus 5. But the first question is whether new phone going to have a probability greater than 1/7 of failing due to something other than user error in years 2 and 3? For an extended warranty to provide any benefit the phone has to have a problem that doesn’t occur in the first year (or a problem in a replacement phone after the first phone was replaced). The phone also has to not be lost, stolen, or dropped in a pool by it’s owner. While my wife and I have a good record of not losing or breaking phones the probability of it happening isn’t zero.

The Nexus 5 that just died can be replaced for 2/3 of the original price. The value of the old Nexus 5 to me is less than 2/3 of the original price as buying a newer better phone is the option I want. The value of an old phone to me decreases faster than the replacement cost because I don’t want to buy an old phone.

For an extended warranty to be a good deal for me I think it would have to cost significantly less than 1/10 of the purchase price due to the low probability of failure in that time period and the decreasing value of a replacement outdated phone. So even though my last choice to skip an extended warranty ended up not paying out I expect that overall I will be financially ahead if I keep self-insuring, and I’m sure that I have already saved money by self-insuring all my previous devices.

Related posts:

  1. The Nexus 5 The Nexus 5 is the latest Android phone to be...
  2. Nexus 4 Ringke Fusion Case I’ve been using Android phones for 2.5 years and...
  3. Nexus 4 My wife has had a LG Nexus 4 for about...

Stewart Smith: Workaround for opal-prd using 100% CPU

Thu, 2016-10-20 19:00

opal-prd is the Processor RunTime Diagnostics daemon, the userspace process that on OpenPower systems is responsible for some of the runtime diagnostics. Although a userspace process, it memory maps (as in mmap) in some code loaded by early firmware (Hostboot) called the HostBoot RunTime (HBRT) and runs it, using calls to the kernel to accomplish any needed operations (e.g. reading/writing registers inside the chip). Running this in user space gives us benefits such as being able to attach gdb, recover from segfaults etc.

The reason this code is shipped as part of firmware rather than as an OS package is that it is very system specific, and it would be a giant pain to update a package in every Linux distribution every time a new chip or machine was introduced.

Anyway, there’s a bug in the HBRT code that means if there’s an ECC error in the HBEL (HostBoot Error Log) partition in the system flash (“bios” or “pnor”… the flash where your system firmware lives), the opal-prd process may get stuck chewing up 100% CPU and not doing anything useful. There’s https://github.com/open-power/hostboot/issues/67 for this.

You will notice a problem if the opal-prd process is using 100% CPU and the last log messages are something like:

HBRT: ERRL:>>ErrlManager::ErrlManager constructor. HBRT: ERRL:iv_hiddenErrorLogsEnable = 0x0 HBRT: ERRL:>>setupPnorInfo HBRT: PNOR:>>RtPnor::getSectionInfo HBRT: PNOR:>>RtPnor::readFromDevice: i_offset=0x0, i_procId=0 sec=11 size=0x20000 ecc=1 HBRT: PNOR:RtPnor::readFromDevice: removing ECC... HBRT: PNOR:RtPnor::readFromDevice> Uncorrectable ECC error : chip=0,offset=0x0

(the parameters to readFromDevice may differ)

Luckily, there’s a simple workaround to fix it all up! You will need the pflash utility. Primarily, pflash is meant only for developers and those who know what they’re doing. You can turn your computer into a brick using it.

pflash is packaged in Ubuntu 16.10 and RHEL 7.3, but you can otherwise build it from source easily enough:

git clone https://github.com/open-power/skiboot.git cd skiboot/external/pflash make

Now that you have pflash, you just need to erase the HBEL partition and write (ECC) zeros:

dd if=/dev/zero of=/tmp/hbel bs=1 count=147456 pflash -P HBEL -e pflash -P HBEL -p /tmp/hbel

Note: you cannot just erase the partition or use the pflash option to do an ECC erase, you may render your system unbootable if you get it wrong.

After that, restart opal-prd however your distro handles restarting daemons (e.g. systemctl restart opal-prd.service) and all should be well.

Binh Nguyen: Common Russian Media Themes, Has Western Liberal Capitalist Democracy Failed?, and More

Tue, 2016-10-18 03:22
After watching international media for a while (particularly those who aren't part of the standard 'Western Alliance') you'll realise that their are common themes: - they are clearly against the current international order. Believe that things will be better if changed. Wants the rules changed (especially as they seemed to have favoured some countries who went through the World Wars relatively

Tridge on UAVs: CanberraUAV Outback Challenge 2016 Debrief

Mon, 2016-10-17 18:17

I have finally written up an article on our successful Outback Challenge 2016 entry

The members of CanberraUAV are home from the Outback Challenge and life is starting to return to normal after an extremely hectic (and fun!) time preparing our aircraft for this years challenge. It is time to write up our usual debrief acticle to give those of you who weren't able to be there some idea of what happened.

For reference here are the articles from the 2012 and 2014 challenges:

http://diydrones.com/profiles/blogs/canberrauav-outback-challenge-2012-debrief
http://diydrones.com/profiles/blogs/canberrauav-outback-challenge-2014-debrief

Medical Express

The Outback Challenge is held every two years in Queensland, Australia. As the challenge was completed by multiple teams in 2014 the organisers needed to come up with a new challenge. The new challenge for 2016 was called "Medical Express" and the challenge was to retrieve a blood sample from Joe at a remote landing site.

outback-joe.jpg762x562 217 KB

The back-story is that poor Outback Joe is trapped behind flood waters on his remote property in Queensland. Unfortunately he is ill, and doctors at a nearby hospital need a blood sample to diagnose his illness. A UAV is called in to fly a 23km path to a place where Joe is waiting. We only know Joes approximate position (within 100 meters) so
first off the UAV needs to find Joe using an on-board camera. After finding Joe the aircraft needs to find a good landing site in an area littered with obstacles. The landing site needs to be more than 30 meters from Joe (to meet CASA safety requirements) but less than 80 meters (so Joe doesn't have to walk too far).

The aircraft then needs to perform an automatic landing, and then wait for Joe to load the blood sample into an easily accessible carrier. Joe then presses a button to indicate he is done loading the blood sample. The aircraft needs to wait for one minute for Joe to get clear, and then perform an automatic takeoff and flight back to the home location to deliver the blood sample to waiting hospital staff.

That story hides a lot of very challenging detail. For example, the UAV must maintain continuous telemetry contact with the operators back at the base. That needs to be done despite not knowing exactly where the landing site will be until the day before the challenge starts.

Also, the landing area has trees around it and no landing strip, so a normal fixed wing landing and takeoff is very problematic. The organisers wanted teams to come up with a VTOL solution and in this
they were very successful, kickstarting a huge effort to develop the VTOL capabilities of multiple open source autopilot systems.

The organisers also had provided a strict flight path that the teams have to follow to reach the search area where Joe is located. The winding path over the rural terrain of Dalby is strictly enforced, with any aircraft breaching the geofence required to immediately and automatically terminate by crashing into the ground.

The organisers also gave quite a wide range of flight distance and weather conditions that the teams had to be able to cope with. The distance to the search area could be up to 30km, meaning a round trip distance of 60km without taking into account all the time spent above the search area trying to find Joe. The teams had to be able to fly in up to 25 knots average wind on the ground, which could mean well over 30 knots in the air.

The mission also needed to be completed in one hour, including the time for spent loading the blood sample and circling above Joe.

Russell Coker: Improving Memory

Mon, 2016-10-17 17:02

I’ve just attended a lecture about improving memory, mostly about mnemonic techniques. I’m not against learning techniques to improve memory and I think it’s good to teach kids a variety of things many of which won’t be needed when they are younger as you never know which kids will need various skills. But I disagree with the assertion that we are losing valuable skills due to “digital amnesia”.

Nowadays we have programs to check spelling so we can avoid the effort of remembering to spell difficult words like mnemonic, calendar apps on our phones that link to addresses and phone numbers, and the ability to Google the world’s knowledge from the bathroom. So the question is, what do we need to remember?

For remembering phone numbers it seems that all we need is to remember numbers that we might call in the event of a mobile phone being lost or running out of battery charge. That would be a close friend or relative and maybe a taxi company (and 13CABS isn’t difficult to remember).

Remembering addresses (street numbers etc) doesn’t seem very useful in any situation. Remembering the way to get to a place is useful and it seems to me that the way the navigation programs operate works against this. To remember a route you would want to travel the same way on multiple occasions and use a relatively simple route. The way that Google maps tends to give the more confusing routes (IE routes varying by the day and routes which take all shortcuts) works against this.

I think that spending time improving memory skills is useful, but it will either take time away from learning other skills that are more useful to most people nowadays or take time away from leisure activities. If improving memory skills is fun for you then it’s probably better than most hobbies (it’s cheap and provides some minor benefits in life).

When I was in primary school it was considered important to make kids memorise their “times tables”. I’m sure that memorising the multiplication of all numbers less than 13 is useful to some people, but I never felt a need to do it. When I was young I could multiply any pair of 2 digit numbers as quickly as most kids could remember the result. The big difference was that most kids needed a calculator to multiply any number by 13 which is a significant disadvantage.

What We Must Memorise

Nowadays the biggest memory issue is with passwords (the Correct Horse Battery Staple XKCD comic is worth reading [1]). Teaching mnemonic techniques for the purpose of memorising passwords would probably be a good idea – and would probably get more interest from the audience.

One interesting corner-case of passwords is ATM PIN numbers. The Wikipedia page about PIN numbers states that 4-12 digits can be used for PINs [2]. The 4 digit PIN was initially chosen because John Adrian Shepherd-Barron (who is credited with inventing the ATM) was convinced by his wife that 6 digits would be too difficult to memorise. The fact that hardly any banks outside Switzerland use more than 4 digits suggests that Mrs Shepherd-Barron had a point. The fact that this was decided in the 60’s proves that it’s not “digital amnesia”.

We also have to memorise how to use various supposedly user-friendly programs. If you observe an iPhone or Mac being used by someone who hasn’t used one before it becomes obvious that they really aren’t so user friendly and users need to memorise many operations. This is not a criticism of Apple, some tasks are inherently complex and require some complexity of the user interface. The limitations of the basic UI facilities become more obvious when there are operations like palm-swiping the screen for a screen-shot and a double-tap plus drag for a 1 finger zoom on Android.

What else do we need to memorise?

Related posts:

  1. Xen Memory Use and Zope I am currently considering what to do regarding a Zope...
  2. Improving Computer Reliability In a comment on my post about Taxing Inferior Products...
  3. Chilled Memory Attacks In 1996 Peter Gutmann wrote a paper titled “Secure Deletion...

Clinton Roy: In Memory of Gary Curtis

Sun, 2016-10-16 17:00

This week we learnt of the sad passing of a long term regular attendee of Humbug, Gary Curtis. Gary was often early, and nearly always the last to leave.

One  of Gary’s prized possessions was his car, more specifically his LINUX number plate. Gary was very happy to be our official airport-conference shuttle for linux.conf.au keynote speakers in 2011 with this number plate.

Gary always had very strong opinions about how Humbug and our Humbug organised conferences should be run, but rarely took to running the events himself. It became a perennial joke at Humbug AGMs that we would always nominate Gary for positions, and he would always decline. Eventually we worked out that Humbug was one of the few times Gary wasn’t in charge of a group, and that was relaxing for him.

A topic that Gary always came back to was genealogy, especially the phone app he was working on.

A peculiar quirk of Humbug meetings is that they run on Saturday nights, and thus we often have meetings at the same time as Australian elections. Gary was always keen to keep up with the election on the night, often with interesting insights.

My most personal memory of Gary was our road trip after OSDC New Zealand, we did something like three days of driving around in a rental car, staying at hotels along the way. Gary’s driving did little to impress me, but he was certainly enjoying himself.

Gary will be missed.

 


Filed under: Uncategorized

Glen Turner: Activating IPv6 stable privacy addressing from RFC7217

Thu, 2016-10-13 11:34
Understand stable privacy addressing

In Three new things to know about deploying IPv6 I described the new IPv6 Interface Identifier creation scheme in RFC7217.* This scheme results in an IPv6 address which is stable, and yet has no relationship to the device's MAC address, nor can an address generated by the scheme be used to track the machine as it moves to other subnets.

This isn't the same as RFC4941 IP privacy addressing. RFC4941 addresses are more private, as they change regularly. But that instability makes attaching to a service on the host very painful. It's also not a great scheme for support staff: an unstable address complicates network fault finding. RFC7217 seeks a compromise position which provides an address which is difficult to use for host tracking, whilst retaining a stable address within a subnet to simplify fault finding and make for easy hosting of services such as SSH.

The older RFC4291 EUI-64 Interface Identifier scheme is being deprecated in favour of RFC7217 stable privacy addressing.

For servers you probably want to continue to use static addressing with a unique address per service. That is, a server running multiple services will hold multiple IPv6 addresses, and each service on the server bind()s to its address.

Configure stable privacy addressing

To activate the RFC7217 stable privacy addressing scheme in a Linux which uses Network Manager (Fedora, Ubuntu, etc) create a file /etc/NetworkManager/conf.d/99-local.conf containing:

[connection] ipv6.ip6-privacy=0 ipv6.addr-gen-mode=stable-privacy

Then restart Network Manager, so that the configuration file is read, and restart the interface. You can restart an interface by physically unplugging it or by:

systemctl restart NetworkManagerip link set dev eth0 down && ip link set dev eth0 up

This may drop your SSH session if you are accessing the host remotely.

Verify stable privacy addressing

Check the results with:

ip --family inet6 addr show dev eth0 scope global 1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2001:db8:1:2:b03a:86e8:e163:2714/64 scope global noprefixroute dynamic valid_lft 2591932sec preferred_lft 604732sec

The highlighted Interface Identifier part of the IPv6 address should have changed from the EUI-64 Interface Identifier; that is, the Interface Identifier should not contain any bytes of the interface's MAC address. The other parts of the IPv6 address — the Network Prefix, Subnet Identifier and Prefix Length — should not have changed.

If you repeat the test on a different subnet then the Interface Identifier should change. Upon returning to the original subnet the Interface Identifier should return to the original value.

Maxim Zakharov: One more fix for AMP WordPress plugin

Thu, 2016-10-13 11:05

With the recent AMP update at Google you may notice increased number of AMP parsing errors in your search console. They look like

The mandatory tag 'html ⚡ for top-level html' is missing or incorrect.

Some plugins, e.g. Add Meta Tags, may alter language_attributes() using 'language_attributes' filter and adding XML-related attributes which are disallowed (see www.ampproject.org/docs/reference/spec#required-markup ) and that causes the error mentioned above.

I have made a fix solving this problem and made pull request for WordPress AMP plugin, you may see it here:
github.com/Automattic/amp-wp/pull/531

Linux Users of Victoria (LUV) Announce: LUV Main November 2016 Meeting: The Internet of Toys / Special General Meeting / Functional Programming

Tue, 2016-10-11 03:02
Start: Nov 2 2016 18:30 End: Nov 2 2016 20:30 Start: Nov 2 2016 18:30 End: Nov 2 2016 20:30 Location: 

6th Floor, 200 Victoria St. Carlton VIC 3053

Link:  http://luv.asn.au/meetings/map

Speakers:

• Nick Moore, The Internet of Toys: ESP8266 and MicroPython
• Special General Meeting
• Les Kitchen, Functional Programming

200 Victoria St. Carlton VIC 3053 (the EPA building)

Late arrivals needing access to the building and the sixth floor please call 0490 627 326.

Before and/or after each meeting those who are interested are welcome to join other members for dinner. We are open to suggestions for a good place to eat near our venue. Maria's on Peel Street in North Melbourne is currently the most popular place to eat after meetings.

LUV would like to acknowledge Red Hat for their help in obtaining the venue.

Linux Users of Victoria Inc. is an incorporated association, registration number A0040056C.

November 2, 2016 - 18:30

read more