From efff310635432b0217b04b1c8181a827e22d25b5 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Tue, 7 May 2013 12:16:05 -0400 Subject: [PATCH] pyafm: Use 'open source' instead of 'FLOSS' Less jargon, and more consistency (e.g. with my title ;). The libre distinction is small, and not particularly critical to this paper. I think it is essential that labs let you see their experiment control software (eakly open source). Whether or not their license allows for sharing is less critical, although without significant funding differences, I expect share-alike software to quickly surpass no-derivatives software in terms of functionality. --- src/pyafm/conclusions.tex | 2 +- src/pyafm/frameworks.tex | 29 ++++++++++++++--------------- src/pyafm/stack.tex | 4 ++-- 3 files changed, 17 insertions(+), 18 deletions(-) diff --git a/src/pyafm/conclusions.tex b/src/pyafm/conclusions.tex index eebf294..8e044f2 100644 --- a/src/pyafm/conclusions.tex +++ b/src/pyafm/conclusions.tex @@ -19,7 +19,7 @@ stack\footnote{% }, and I've spent the remaining time tuning this stack (and the analysis software) while running experiments. -A FLOSS stack allows collaborative development so that this +An open source stack allows collaborative development so that this development cost can be shared between labs, as well as lowering the barrier to entry for new labs entering the field. Besides benefiting SMFS groups, lower-level packages in the stack will be useful to a diff --git a/src/pyafm/frameworks.tex b/src/pyafm/frameworks.tex index 216ac12..e913acc 100644 --- a/src/pyafm/frameworks.tex +++ b/src/pyafm/frameworks.tex @@ -8,9 +8,9 @@ computers to control and monitor arbitrary physical processes is common in the scientific community and industry, but less so in the the general consumer market. This means that interfaces between the digital and analog worlds haven't seen the focused development in the -FLOSS community that more mainstream problem areas have received. In -this section I'll discuss a few possible options---both open and -proprietary---in the context of my experiment control stack. +open source community that more mainstream problem areas have +received. In this section I'll discuss a few possible options---both +open and proprietary---in the context of my experiment control stack. \subsection{LabVIEW} \label{sec:labview} @@ -83,20 +83,18 @@ recover earlier versions of the project. For example, if you find a bug in your package, you can use your VCS to determine if that bug affected the data you gathered six months ago. -There are a number of FLOSS version control systems in common use -(Git, Mercurial, and Subversion, \dots), but in order to track and +There are a number of open source version control systems in common +use (Git, Mercurial, and Subversion, \dots), but in order to track and merge \emph{changes}, they need a way to calculate the difference between two versions of a given file. For textual programming languages, the line-based textual differences used by VCSs work extremely well, but for binary file formats, performance decreases drastically. There are third-party merge tools\citep{ni-merge} for LabVIEW, but the tools are not officially supported. - +% \nomenclature{VCS}{Version control system. A system for tracking project development by recording versions of the project in a repository.} -\nomenclature{FLOSS}{Free, Libre, and Open Source (software). A - catch-all for copyleft licensing.} While National Instruments seems to put a reasonable amount of effort into maintaining backwards compatibility, long term archival of binary @@ -134,7 +132,7 @@ The overhead of sending all the data through sockets to generic hardware interface modules was larger than I had na\"{\i}vely expected. I also had trouble with multithreaded socket code on Cygwin, and decided to drop Microsoft Windows altogether in favor of -a FLOSS operating system. +an open source operating system. \begin{figure} \begin{center} @@ -168,12 +166,13 @@ static int set_digital_output_data(DIGITAL_OUTPUT *d, unsigned int data) After transitioning to Linux-based systems, I could no longer use NI-DAQmx (which only supported Microsoft Windows). Luckily, the -\citetalias{comedi} project already provided FLOSS driver code for our -DAQ card (an NI-PCI-6052E). Comedi (from ``Control and Measurement -Device Interface'') is a general purpose library for interacting with -DAQ devices, and supports a wide range of hardware. When I moved to -Comedi, it was a stand-alone kernel module, but since November 2008 it -has been included in the Linux source as a staging driver. +\citetalias{comedi} project already provided open source driver code +for our DAQ card (an NI-PCI-6052E). Comedi (from ``Control and +Measurement Device Interface'') is a general purpose library for +interacting with DAQ devices, and supports a wide range of hardware. +When I moved to Comedi, it was a stand-alone kernel module, but since +November 2008 it has been included in the Linux source as a staging +driver. Comedi development goes back to 2000, so by the time I arrived things were already pretty stable. I submitted diff --git a/src/pyafm/stack.tex b/src/pyafm/stack.tex index c0be6aa..130a274 100644 --- a/src/pyafm/stack.tex +++ b/src/pyafm/stack.tex @@ -2,8 +2,8 @@ \label{sec:pyafm:stack} In order to reduce future maintenance costs, I have based my stack as -much as possible on existing FLOSS software, and split my stack into -reusable components where such components might appeal to a wider +much as possible on existing open source software, and split my stack +into reusable components where such components might appeal to a wider audience. From the bottom up, \pycomedi\ wraps the Comedi device driver for generic input/output, \pypiezo\ builds generic piezo-control logic on top of \pycomedi, \pyafm\ combines a -- 2.26.2