In December 2015 I saw the
kickstarter for the Pine64. The project seemed to have a viable hardware design and after my
experience with the hikey I decided it could not be a great deal worse.
The system I acquired comprises of:
- Quad core Allwinner A64 processor clocked at 1.2GHz
- 2 Gigabytes of DDR3 memory
- Gigabit Ethernet
- two 480Mbit USB 2.0 ports
- HDMI type A
- micro SD card for storage.
Hardware based kickstarter projects are susceptible to several issues and the usual suspects occurred causing delays:
- Inability to scale, several thousand backers instead of the hundred they were aiming for
- Issues with production
- Issues with shipping
My personal view is that PINE 64 inc. handled it pretty well, much better than several other projects I have backed and as my Norman Douglas quotation suggests I think they have gained some wisdom from this.
I received my hardware at the beginning of April only a couple of months after their initial estimated shipping date which as these things go is not a huge delay. I understand some people who had slightly more complex orders were just receiving their orders in late June which is perhaps unfortunate but still well within kickstarter project norms.
As an aside: I fear that many people simply misunderstand the crowdfunding model for hardware projects and fail to understand that they are not buying a finished product, on the other side of the debate I think many projects need to learn expectation management much better than they do. Hyping the product to get interest is obviously the point of the crowdfunding platform, but over promising and under delivering always causes unhappy customers.
Despite the delays in production and shipping the
information available for the board was (and sadly remains) inadequate. As usual I wanted to case my board and there were no useful dimension drawings so I had to
make my own from direct measurements together with a STL 3D model.
Also a mental sigh for "yet another poor form factor decision" so another
special case size and design. After putting together a design and fabricating with the laser cutter I moved on to the software.
Once more this is where, once again, the story turns bleak. We find a very pretty website but no obvious link to the software (hint scroll to the bottom and find the "support" wiki link) once you find
the wiki you will eventually discover that the provided software is either an Android 5.1.1 image (which failed to start on my board) or relies on some random guy from the
forums who has put together his own OS images using a hacked up Allwinner Board Support Package (BSP) kernel.
Now please do not misunderstand me, I think the work by
Simon Eisenmann (longsleep) to get a
working kernel and
Lenny Raposo to get viable OS images is outstanding and useful. I just feel that Allwinner and vendors like Pine64 Inc. should have provided something much, much better than they have. Even the
efforts to get mainline support for this hardware are all completely volunteer community efforts and are are making slow progress as a result.
Assuming I wanted to run a useful OS on this hardware and not just use it as a modern work of art I installed a basic Debian arm64 using Lenny Raposo's
pine64 pro site downloads. I was going to use the system for compiling and builds so used the "Debian Base" image to get a minimal setup. After generating unique ssh keys, renaming the default user and checking all the passwords and permissions I convinced myself the system was reasonably trustworthy.
The standard Debian Jessie OS runs as expected with few surprises. The main concern I have is that there are a number of unpackaged scripts installed (prefixed with pine64_) which perform several operations from reporting system health (using sysfs entries) to upgrading the kernel and bootloader.
While I understand these scripts have been provided for the novice users to reduce support burden, doing even more of the vendors job, I would much rather have had proper packages for these scripts, kernel and bootloader which apt could manage. This would have reduced image creation to a simple debootstrap giving much greater confidence in the images provenance.
The 3.10 based kernel is three years old at the time of writing and lacks a great number of features for the aarch64 ARM processors introduced since release. However I was pleasantly surprised at kvm apparently being available.
# dmesg grep -i kvm
[ 7.592896] kvm [1]: Using HYP init bounce page @b87c4000
[ 7.593361] kvm [1]: interrupt-controller@1c84000 IRQ25
[ 7.593778] kvm [1]: timer IRQ27
[ 7.593801] kvm [1]: Hyp mode initialized successfully
I installed the libvirt packages (and hence all their dependencies like qemu) and created a bridge ready for the virtual machines.
I needed access to storage for the host disc images and while I could have gone the route of using USB attached SATA as with the hikey I decided to try and use network attached storage instead. Initially I investigated iSCSI but it seems the Linux target (iSCSI uses initiator for client and target for server) support is either
old,
broken or
unpackaged.
I turned to
network block device (nbd) which is packaged and seems to have reasonable stability out of the box on
modern distributions. This appeared to work well, indeed over the gigabit Ethernet interface I managed to get a sustained 40 megabytes a second read and write rate in basic testing. This is better performance than a USB 2.0 attached SSD on the hikey
I fired up the guest and perhaps I should have known better than to expect a 3.10 vendor kernel to cope. The immediate hard crashes despite tuning many variables convinced me that virtualisation was not viable with this kernel.
So abandoning that approach I attempted to run the CI workload directly on the system. To my dismay this also proved problematic. The processor has the bad habit of throttling due to thermal issues (despite a substantial heatsink) and because the storage is network attached throttling the CPU also massively impacts I/O.
The limitations meant that the workload caused the system to move between high performance and almost no progress on a roughly ten second cycle. This caused a simple NetSurf recompile CI job to take over fifteen minutes. For comparison the same task takes the armhf builder (CubieTruck) four minutes and a 64 bit x86 build which takes around a minute.
If the workload is tuned to a single core which does not trip thermal throttling the build took seven minutes. which is almost identical to the existing single core virtual machine instance running on the hikey.
In conclusion the Pine64 is an interesting bit of hardware with fatally flawed software offering. Without Simon and Lenny providing their builds to the community the device would be practically useless rather than just performing poorly. There appears to have been no progress whatsoever on the software offering from Pine64 in the six months since I received the device and no prospect of mainline Allwinner support for the SoC either.
Effectively I have spent around 50usd (40 for the board and 10 for the enclosure) on a failed experiment. Perhaps in the future the software will improve sufficiently for it to become useful but I do not hold out much hope that this will come from Pine64 themselves.
Yesterday, the motranslator 2.0 has been released. As the version change suggests there are some important changes under the hood.
Full list of changes:
Authenticating HTTPS clients using TLS certificates has long been very
easy to do. The hardest part, in fact, is to create a PKI infrastructure
robust enough so that compromised (or otherwise no longer desirable)
certificates cannot be used anymore. While setting that up can be fairly
involved, it's all pretty standard practice these days.
But authentication using a private CA is laughably easy. With apache,
you just do something like:
Yesterday evening I was enjoying several features by 
Not only since the unprecedented warning to 
Two years ago in 
Hello folks! My team spent hours and hours beating our head against a Sonar deployment problem on Ubuntu Trusty (14.04 LTS). I thought I might share our findings so that you won t have to!
As you probably know, Trusty only makes Java Development Kit 1.7 available on the stock installation. The current stable version of the Java is 1.8. The way we install this is to use the 
To make things worse, this option is not, as one might expect, available for editing in a stock Jenkins 2.x installation. In Jenkins 1.x, one would be able to specify which java one wished to use just by specifying openjdk8 in a field. With Jenkins 2.x, the field does not exist unless a configuration option in an unrelated form is set.
So! One should first select Manage Jenkins -> Global Tool Configuration:
Once this form is open, look for the JDK installations button:
Click it very thoroughly just once.
You ll be presented with a form into which you may enter details about the various JDKs your build executors may have access to. You ll refer to them in your job configuration by the value of their Name field, and when executing the build, Jenkins will set JAVA_HOME to the value of the (you guessed it) JAVA_HOME field:
Once these entries are made, they can be selected in two place.
1) on the ZMQ Event Publisher:
2) in the post-build actions under SonarQube analysis with Maven (advanced)
And that s how it s done!
Here s the details from my colleague, Thanh:
At the moment, it contains 
Ready to use today
More confident users will be able to build the ISO and use it immediately by operating all the utilities from the command line. For example, you should be able to 
