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/Docear.app/Contents/MacOS/FreeplaneJavaApplicationStub
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

Introduction

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.

Instructions

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 softwarecollections.org


yum localinstall https://www.softwarecollections.org/en/scls/rhscl/python33/epel-7-x86_64/download/rhscl-python33-epel-7-x86_64.noarch.rpm
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


#!/bin/sh
scl enable python33 -- python $@

Then compile and install Backintime from the downloaded


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

OERs: Publishing Software – Open source or Open API

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.

I have been asked to comment on the use of “free” open source applications in the context of OERs.  I blogged about this just recently.  My classmate, Stu has responded to the same question in his blog post where he discusses the virtues of open source software in the creation of content in Education. Comparisons have also been drawn between the virtues of open source software, and open educational resources.  It is true that there are some similarities in the spirit of each of these models of publishing and sharing.  Like me in my blog post, Stu highlights the benefits of free technology such as Google Apps in education. However, a clear distinct needs to be made – Google Apps is not open source software.

Google Apps is part of a new breed of software known as cloud computing software.  It brings new ways of sharing and re-using information.  While in spirit, cloud computing software appears to be “open source”, it is in fact typically “open API“.  So what is an API?  In short, it is a published and standardised way for computer programs to interact with one another, typically on the web.

An example will do well here.  Consider flickr.  There are many different software products for uploading your photos into flickr. Each of these products uses the Flickr API to login to your flickr account, select your photo files, tag them, title them, and upload them into Flickr, and so on. Google has similar APIs for interacting with their Google Apps services, and in fact most of their cloud services.

While the API is open and anyone (who is authorised by the service provider) can write programs to interact with the service, the service software programming source code isn’t is open.  So it’s behaviour cannot be changed or extended or adapted for other contexts.  It also means that if the service provider decides to change the terms of the service (Ning) or simply decides to shut them down (ask Google Wave customers about that), then you are out of luck.

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.

Google’s terms of service for Picasa just stink!

I am looking for an option for sharing my photos with family and friends.  I like the licence agreement afforded by flickr, but sadly I would also like a client interface that provides simple and efficient synchronisation of my photo albums.  I want to be able to add my tags, captions, titles, descriptions and photo albums in a local application, and then replicate that to an online presence with a single click.  I have yet to find this for flickr.  Picasa on the other hand provides this functionality in conjunction with Google Web Albums, and I was all but ready to sign up until I read their terms of service.

Point 11.1 states:

11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.

As pointed out by  Sam, it is abhorrent to think that by simply using their services, you are granting them a “perpetual, irrevocable, worldwide, royalty-free” licence to your images to “promote” their services.  Even if you cancel your agreement with Googe in using their service, they still have perpetual access to your content.

By contrast, Yahoo!7 has this to say regarding their services (including Flickr):

With respect to photos, graphics, audio or video you submit or make available for inclusion on publicly accessible areas of the Service other than Yahoo!7 Groups, the license to use, distribute, reproduce, modify, adapt, publicly perform and publicly display such Content on the Service solely for the purpose for which such Content was submitted or made available. This license exists only for as long as you elect to continue to include such Content on the Service and will terminate at the time you remove or Yahoo!7 removes such Content from the Service.

Note that if you remove the content from their service, you also revoke their licence to use it.  Furthermore, the licence only applies to contact you make publicly available – perfectly reasonable and necessary for them to carry out the service.  So your private photos that you share only with your friends and family are off limits.  Congrats to Yahoo for taking such a fair and reasonable approach to their terms of service.

Come on google, don’t be so greedy.