Docear on macOS: Navigating the Apple Java Nightmare

So this blog post will be brief, as I suppress my disdain for Apple’s attitude towards Java, now that they no longer need it to survive due to their App Store ecosystem.

This blog post documents how I was able to get the Docear Mindmapping software working on OSX El Capitan (10.11).

Sadly, many Java applications which should ‘run anywhere’ simply don’t anymore on the Mac.  Apple abandoned their own internal version of the JRE and bundling with the OS, and deferred said support to the author of Java, now Oracle.  Oracle, too have contributed to the nightmare in providing little assistance in making the transition seamless.

After installing Docear on my mac, I attempted to start it with the icon in the Applications folder in the usual way only to find it bounce in the dock once, and disappear.  How rude I thought.  So I resorted to the command line (gotta love UNIX-like desktops).  When I attempted to start it there, I was presented with the ugly error message:

$ /Applications/
JavaVM: Failed to load JVM: /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/bundle/Libraries/libserver.dylib
JavaVM: Failed to load JVM: /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/bundle/Libraries/libserver.dylib
JavaVM FATAL: Failed to load the jvm library.
[JavaAppLauncher Error] JNI_CreateJavaVM() failed, error: -1

Just lovely.  I actually thought I was running Java JRE 1.8 that I downloaded from Oracle.  Seems there are other versions lurking on my system.

I’ll spare you all the drudgery of diagnosing this issue and coming up with a solution.  I will tip my hat to Oliver Dowling and his blog post which eventually lead me to the solution below.  One thing I did learn is that creating a symbolic link for libserver.dylib did not work for me.  I had to instead create a hard link.  I suspect the JRE stub FreeplanJavaApplicationStubJavaVM binary was checking for the existence of a ‘normal’ file rather than ‘a’ file.

Anyway, here are the goods to make Docear work on OSX10.11 (and hopefully other versions).  Be sure to substitute the Java version numbers in the file paths with your version of Java installed.

$ cd /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home
$ sudo ln -s jre/lib bundle
$ cd bundle
$ sudo mkdir Libraries
$ sudo ln /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/lib/server/libjvm.dylib libserver.dylib

Hopefully after executing these commands, you will be able to use Docear.  Good luck!

How to Install Backintime Backup Software on CentOS/RHEL/Scientific Linux 7


Hopefully the title of this post is explanation enough.

Backintime is a neat backup solution that mimics in some ways, the abilities of OSX’ Timemachine backup system.  At predetermined time intervals, Backintime will sweep configured directories on your computer, and only backup the differences since the last sweep.  It results in an efficient use of storage resources on your backup destination drive by hard linking identical files.  Unlike the OSX Timemachine solution, it does not hard link directories, as only Apple’s HFS+ filesystem supports hard-linked directories.  This makes Backintime portable to Unix-based Operating Systems using a variety of filesystems.

The reason for this post is to document some trickery necessary to make Backintime work on our favourite North American Linux vendor’s enterprise operating system, the derivative on which that I use being CentOS 7.  CentOS 7 like its other cousins in the Red Hat family only includes Python interpreter version 2.  While Backintime is written in Python 3.  I have had only a little experience with Python, and it does have some great features (built in multi-threading), however making the two versions incompatible is such a nuisance.  Whinge over, the trick to allowing Backintime to work on CentOS 7 is to install a 3rd party Python 3 interpreter.  The following instructions achieve this end.


Download Backintime from their website, and follow the installation instructions from the README file.

Next, you will need to install a 3rd-party YUM Repository called

yum localinstall
yum install python33

Then create a script file to execute the python3 interpreter with the command python3 by creating the following shell script as the file /usr/local/bin/python3

scl enable python33 -- python $@

Then compile and install Backintime from the downloaded

./configure --python3 && make && make install

Week 4: OER Content Creation

This blog post relates to my study of Open Educational Resources as part of my Emerging Technologies for Learning Program of study at the University of Manitoba. Questions for this week in my course are:

How familiar are you with these [Audacity, GIMP, Joomla, Drupal, WordPress, Blogger, Open Office, Google Docs, Blender, and so on] tools? How can you use them to create and develop content for use in your own institution? What personal or general perceptions characterize your use of “free” open source applications in your institution for teaching, learning or working purposes (whichever applies)?

Not surprisingly, given my IT background, I have been using open-source software for all sorts of applications for many years.  At one stage, I designed, built and managed an 86-node supercomputing facility using nothing but open source software, thus maximising investment in providing the highest capacity computer hardware.  A similar approach to maximising the efficient use of funds, as described by Stu.  I have used many of the software products described in the OER Handbook.

Most of the software that I use today for content creation is provided online as a service.  Software for creation and publishing has converged to the extent that they are often one and the same.  Googledocs, is a classic example of this and is something that I frequently use.  It’s desktop publishing functionality is quite poor (try nicely formatting a Googledoc – blah), however its collaborative writing capabilities are very innovative.  Watching a co-author’s cursor skirt about the same document you are writing, and watching them type was such a buzz the first time I saw it.  Your document can be published at any stage of its development, and can continue to evolve after it’s been published.  Skills required to use googledocs stray little from those to use a typical word processor such as MS-Word.  I tend to only use MS-Word when I need to professionally format my final document, usually for hardcopy production.  This is becoming less and less common.

I also mention Googledocs specifically because my institution has adopted Google Apps for Education – a suite of hosted services from Google including Gmail, Googledocs, Google Sites and so on, specifically for educational institutions.  One of the marketing points for this service is that it is free for the institution, and the accounts provided to students are free for life, even after they graduate.  They keep their email address too.  I see such promise in the use of these creation/publication products.  But alas, I think they have been underutilised since their introduction at my institution.  Reasons vary, but one is that there is little integration of the google apps into our existing online systems, and in particular Moodle.  Simple things like the ability to automatically create and share an empty googledoc based on groups of students within a Moodle course – the simple no fuss beginnings of a group-essay.  When marking, you can also see the contributions of each group-member to the document through the revision history.

Yes, like many Universities in Australia and New Zealand, our institution is using Moodle as our Learning Management System.  Moodle is an open-source product and we have customised our installation enhancing its capabilities, integrating it with other aspects of our organisation, and adapting its functionality to our own operational needs.  Not always easy to do with a proprietary system.  The use of this open-source software however does very little for the OER movement, because all our course content is locked behind a username and password.

Moodle at our institution is generally understood to be the central learning technology for our students.  There are a handful of academics who venture outside the walls of Moodle and use alternate technologies, but they do so at their own risk, and without the institutional support of the IT department.  Even the use of youtube is discouraged in favour of an internally written video uploader in Moodle, on the grounds of tracking metadata of the content.  This video uploader is only a recent addition to Moodle.

So exposure to software well suited to the creation of OERs is limited in my context.