The One by OnePlus is a flagship phone designed and produced by the Chinese startup OnePlus founded in December 2013. Only a few months later, the company announced the phone in April 2014. The astonishing speed can be explained if you know that the company’s founder, Pete Lau, previously was Vice President at Oppo Electronics and is no newcomer to the smartphone business.

The phone’s specs are clearly targeted at the high-end market. For example, it features a 2.5 GHz quad-core CPU, 3 gigabytes of DDR3 RAM, a 1080p IPS display and a 3100 mAh battery. The official website has the details – there really is no point in repeating all of them here.

I swear, it’s that large

A period of my life is coming to an end. Yesterday’s mail made that all the more obvious to me, since it contained my university diploma. I have now officially graduated Friedrich-Alexander-University of Erlangen-Nuremberg with a Master’s degree in computer science. This is reason for celebration, especially since I managed to pass with distinction, but it is also an opportunity to look back. Since I will not stay at university or in Erlangen, graduation comes with a farewell.

I have enjoyed the last few years in Erlangen, especially at the System Software Group and its KESO Research Project where I wrote my Master’s thesis on “Compiler-Assisted Memory Management Using Escape Analysis in the KESO JVM”. However, in the last few months in Erlangen I’ve realized that it was time to move on and seek new challenges. And I have.

On September 1^st I will take up a job as “software integrator Linux” at BMW Car IT in the city of Ulm. I’m hoping my experience with continuous integration from KESO, package management, and build systems from MacPorts may be helpful at my position. I’m really looking forward to working for BMW and moving to Ulm, and what I’ve seen so far has been fantastic! :-)

Off to pastures new!

MacPorts 2.3.0 has been released. But what’s new for users, and why should they use the new features?

This release contains a lot of changes under the hood that users probably won’t notice. For example, MacPorts no longer uses the system-provided version of Tcl, but ships its own copy. That might seem like a step backward at the first glance, but simplifies compatibility with older systems such as Tiger or Leopard (hello, PPC users), allows us to clean up some of the cruft in the codebase and fix some long-standing issues like signal handling in future releases.

Another change most users won’t notice is the use of HTTP pipelining (I know, I know, what took us so long?), which should be beneficial especially when downloading a lot of binary packages from our mirrors. Also related to downloads, but very much noticeable are the new progress bars. Previously download progress information was only available when run in verbose mode, but 2.3.0 comes with a nice progress indicator for downloads taking longer than a few seconds. You’ll also see the same progress bar in rev-upgrade, which previously indicated its progress using a simple percentage number.

One of the changes I’ve been waiting for (and working on) is “trace mode”. Trace mode is a poor man’s sandbox initially developed for the darwinbuild project at Apple. It is based on library preloading, a technique known from Linux systems using the environment variable LD_PRELOAD. That makes it inherently insecure, but since security (i.e. protection against malicious attackers) has never been a goal for this sandbox, that’s not critical. Trace mode adjusts the environment of a build in MacPorts by hiding all files that shouldn’t be there in a vanilla installation of OS X and files in the MacPorts prefix that aren’t installed by a dependency of the current port. Trace mode is a great tool for both port authors and users: Missing dependencies are easily identified and files in /usr/local can no longer interfere with a MacPorts build with trace mode enabled. This last point is especially important since lots of third party installers and other package managers (looking at you, homebrew) install files in /usr/local. The next time a port fails to build for you, clean and re-try with port -t instead.

Other minor, but helpful new features include a check for the presence of the Xcode Command Line Tools and Xcode license agreement acceptance and a helpful new overview for the select feature at port select --summary.

Despite my switch to a MacBook Pro almost six years ago I still have a Windows box I occasionally use, mostly when I forget to bring my MacBook’s PSU (which happens surprisingly often, despite having two of them for exactly that reason).

Since disk space on rotational drives is cheap these days I switched to a RAID 1 configuration when I last upgraded the hardware in said computer. I went with two Western Digital WD20EARX 2 TB drives and first tried my mainboard’s fake RAID (AMD RAIDXpert on an AMD SB710 chipset). Long story short, I was unsatisfied with the performance and afraid of data loss in case my mainboard dies and I couldn’t get one with the same chipset.

I’ve seen software RAID on Linux and it was working much better for me than my mainboard’s attempt at it, so I figured I’d try the software RAID implemented in Windows 7 (Professional, Enterprise and Ultimate only). Simple to setup and with acceptable sync speeds I thought I had found what I was looking for – but then it seemed every time I rebooted, the disk array would be inconsistent and resync from scratch. Needless to say, performance was plummeting. The machine would hang for seconds waiting for I/O and every reboot would make it all start over. Even worse, the resync couldn’t be aborted and the disk array couldn’t be disbanded either (who at Microsoft thought that was a good idea?).

Turns out the culprit was a known one. KB 2913050 says “Mirrored RAID volumes report Resynching status after you restart Windows 7 […]”, and it would happen after each hotfix package installation, so for infrequently used computers basically every (re-)boot. I especially liked the “resolution”:

Microsoft is aware of this issue and intends to address it in a future release of Windows.

Translation:

It’s broken, but we’re not going to bother fixing it in Windows 7. Give us some money, if you want RAID support.

Or you could set the following magic registry keys, but we’re not going to tell you what they do, how they affect the Volume Shadow Copy Service or why we’re not setting them with a hotfix for everybody.

Please, somebody remind me why I thought Microsoft had a good reputation for their support of business-grade software…

Starting with version 2.3.0, MacPorts will use its own copy of Tcl rather than relying on the Tcl shipped by Apple with OS X. Since MacPorts still works on versions of OS X down to Tiger that only have Tcl 8.4, all features introduced in Tcl 8.5 have been off limits and workarounds had to be used. That turned out to be unsatisfactory, especially avoiding {*} argument expansion (with the ugly workaround of using eval).

The idea of bundling a private copy of Tcl first came up in July 2013 on the macports-dev mailing list, originally in the context of the Apple distribution of Tcl changing in OS X Mavericks in a way that would no longer allow MacPorts to build from source if the optional Command Line Tools package wasn’t installed.

The Problem

MacPorts uses GNU autoconf in its build system. GNU autoconf supports bundling dependencies in subdirectories using the AC_CONFIG_SUBDIRS macro – but it wasn’t sufficient for two reasons:

• The Tcl configure script creates a file that is needed by MacPorts’ configure to find the correct Tcl interpreter and build setup. AC_CONFIG_SUBDIRS will delay configuring subpackages to the very end, but we needed it to be done earlier.
• AC_CONFIG_SUBDIRS will always pass the same arguments given to the main configure script, which includes the prefix setting. That would install our local copy of Tcl to a location that’s being used by the MacPorts tcl port (which is version 8.6 and at the moment incompatible with some of the MacPorts code).

There have been a few attempts at solving similar problems, one of which is a patch against autoconf and has been sent to the autoconf mailinglist in April 2011, but was apparently never applied. I didn’t want to require a patched autoconf to generate the MacPorts configure script either, so applying the patch was not an option.

The Solution

An unsolved problem in a technology I haven’t used a lot yet? That sounded like a great opportunity to learn something new – and so I wrote the missing macro, mostly by reading and copying the source of AC_CONFIG_SUBDIRS and adjusting it where needed. I added extracting from a tarball so I didn’t have to commit the extracted Tcl sources. MP_CONFIG_TARBALL (source) takes the path to a tarball, the directory that’s created by extracting the tarball that contains the configure script and a list of configure parameters to pass to the subproject. Each given configure parameter overrides those given on the main project’s command line and preserves those that have not been overwritten like AC_CONFIG_SUBDIRS would.