Friday 10 January 2014

using Libre office on roll.app on a chrome book

After my 3g router fun, I finally got round to to testing Libre Office via Roll.app on my Chromebook. The test was pretty cursory
  • open an existing document from Dropbox
  • make some changes
  • save them
  • create a new document
  • write some text
  • save it to Dropbox
To carry out the test I connected using my 3g network connection. I found that in use
  • Libre Office slow to initialise - the processing the letter A problem
  • fine for opening existing documents from dropbox
  • creating new documents fine but typing without naming doc first did not work - this could be due to lack of patience on my part
    • this differs from behaviour using chrome on a mac
    • could be artefact of using slower network connection
I fed the resulting newly created document through Apache Tika to look at the technical metadata in the document and everything looked fairly normal - essentially it’s a recent version of Libre office running on Linux.

apache tika test results

Character Count: 55
Content-Length: 8198
Content-Type: application/vnd.oasis.opendocument.text
Creation-Date: 2014-01-09T21:08:51.491268425
Edit-Time: P0D
Image-Count: 0
Last-Modified: 2014-01-09T21:10:25.257548178
Last-Save-Date: 2014-01-09T21:10:25.257548178
Object-Count: 0
Page-Count: 1
Paragraph-Count: 1
Table-Count: 0
Word-Count: 11
date: 2014-01-09T21:08:51.491268425
dcterms:created: 2014-01-09T21:08:51.491268425
dcterms:modified: 2014-01-09T21:10:25.257548178
editing-cycles: 1
generator: LibreOffice/4.1.3.2$Linux_X86_64 LibreOffice_project/70feb7d99726f064edab4605a8ab840c50ec57a
meta:character-count: 55
meta:creation-date: 2014-01-09T21:08:51.491268425
meta:image-count: 0
meta:object-count: 0
meta:page-count: 1
meta:paragraph-count: 1
meta:save-date: 2014-01-09T21:10:25.257548178
meta:table-count: 0
meta:word-count: 11
modified: 2014-01-09T21:10:25.257548178
nbCharacter: 55
nbImg: 0
nbObject: 0
nbPage: 1
nbPara: 1
nbTab: 0
nbWord: 11
resourceName: 00_apache_tika_test.odt
xmpTPg:NPages: 1


While I was at it I also ran the same test with open office writer - behaviour was broadly similar
  • slow startup/initialisation
  • no need to save document before entering text
Some other testing on my 3g connection seems to suggest that there is sometimes a bit of latency starting up web based applications, certainly I don’t see the same problems when starting up either on Chrome on a Mac or Chromium on Linux on a high speed connection at work.

and the processing the letter A problem?

In the eighties I was employed by the University of York as an analyst/programmer officially working some of the time on time sharing Vax based systems. In fact I actually spent most of my time messing about with these new fangled desktop pc’s, text processing, and data capture and migration - no change there then.

However, my alleged status as a Vax programmer meant that I did get to go to various Digital Equipment Company conferences and at a Decus conference at I think Warwick, a guy called Bill Hancock gave a hilarious presentation on the processing the letter A problem.

The scenario was a Vax in a nuclear power plant that was capturing data from various instruments. Now you need to understand that in a time sharing system the task scheduler allocates time between various processes. In theory you could give every process the same slice of the pie but in practice you need to tweak things to ensure adequate disk read and write etc. How you tweak things is up to you but in a data capture situation, if the system is too busy with other things and doesn’t look at the instruments often enough it can miss spikes in the data. Obviously in a nuclear power plant this could be critical (bad pun).

To get Vaxes to be responsive for editing Dec artificially upped the priority of the terminal process, which meant that if a lot of people had active editing sessions open they could starve the other processes of time and you would start missing data - why? because the system was processing the letter A.

The answer of course is to treat data capture as high priority (or to down the terminal session priority a bit rather than just using the out of the box config.)

Incidentally we did late run a word processing system at York on Vaxes using WordPerfect and the enhanced terminal response feature made it usable but at the expense of a slow startup for login sessions. I’m going to guess that some of the latency problems seen with Roll.App is due to starting a process and all the virtualisation stuff that goes with it and getting things set up, the idea being that users will wait for a session to get going.

Except of course they don’t, increasingly people are used to fast responses, in part because a lot of desktop and tablet applications offer near instant gratification …

No comments: