Installing Debian 8.2 as a VirtualBox Virtual Guest in FreeBSD 10.2-STABLE

Synopsis: In order to run the Mendeley and Evernote desktop applications on my FreeBSD laptop -- short of endeavoring to develop a port for each of those, as onto the Centos 6 (C6) Linux emulation layer, in FreeBSD -- previously, I'd installed Microsoft Windows 7 into a VirtualBox virtual guest machine, from a Microsoft DreamSpark installer disk. In a sense, it's "Worked," so far -- as after completing all of the OS installation process, OS update process, and software installation processes onto the virtual guest machine -- "Worked," though, in such that I now have a Microsoft Windows 7 virtual guest machine available for running Microsoft Windows software via VirtualBox on my FreeBSD laptop, but considering the substantial hardware footprint of Microsoft Windows -- as in regards to Microsoft Windows' utilization of system memory and processor resources, whether or not such hardware resources are utilized via a VirtualBox virtual guest machine -- I've estimated that it may be more effective to install Mendeley and Evernote into a Linux virtual guest machine. With those applications installed into a Linux virtual guest machine, and with the Linux operating system (OS) of that virtual guest machine being tuneable as a Linux operating system, I estimate that it may be overall a more effective way to utilize the Mendeley and Evernote desktop applications ultimately on my FreeBSD laptop -- more effective, juxtaposed to the Mendeley and Evernote desktop applications being installed to the, may one say, the more indulgently designed operating system that is Microsoft Windows 7.

Thus, I've downloaded the Debian net installer CD -- using the BitTorrent P2P distribution for downloading the Debian net installer CD, then applying the ctorrent command-line BitTorrent application on my FreeBSD laptop. After some small effort for resolving an initial issue at installation time, I've now installed Debian into a VirtualBox virtual guest machine, on my FreeBSD laptop. Of course, this being a learning experience -- and although the style in which I write about this learning experience may not seem like "Normal English" to some readers' estimations -- I've considered that it may be useful to record some of my own technical observations from this learning experience, specifically of installing Debian 8.2 from the amd64 netinst CD.

Firstly, as in order to so much complete the installation, I've configured the VirtualBox virutal guest machine such that the virtual guest machine would utilize the VirtualBox ICH9 CPU emulation -- juxtaposed to the VirtualBox PIIX3 CPU emulation. When the virtual guest machine was configured, originally, to use the PIIX3 CPU emulation, the installation would "Freeze", reproducibly -- furthermore, always "Freezing" at a specific time, such as when installing the 'passwd' utility during the Debian installer process. My not being immediately predisposed to bug track that specific issue, I've sought a workaround, and have found a workaround of the issue.

Simply, in the graphical configuration panel for the VirtualBox virtual guest machine for the Debian installation -- specifically, in the virtual guest machine 'System'  configuration panel, 'Motherboard' configuration tab -- I've selected the ICH9 Chipset emulation instead of the PIIX3 Chipset emulation. Once making that single change to the configuration for the virtual guest machine, I was able to complete the Debian installation. (Ed. Note: Of course, this configuration change could also be made in applying the 'vboxmanage' shell command,  as may be installed with the VirtualBox OSE port on FreeBSD hosts. The VirtualBox manual describes the 'vboxmanage' shell command, at depth)

In order to create something of a minimalist desktop, in the Debian virtual guest machine, I'd selected the XFCE desktop at installation time. Furthermore, I'd deselected the print server installation task, at that time -- thus limiting the amount of software that the installer would install in the virtual guest machine, before "First boot".

Of course, the Debian virtual guest machine will be applied, on my FreeBSD laptop, not as if for  creating a stand-alone virtual desktop environment of the Debian installation. Rather, ,the Debian virtual guest machine will be applied as to provide some desktop application services, such that may then be presented on the FreeBSD desktop via the VirtualBox "Seamless" display integration -- such that it will then be possible to use the Evernote and Mendeley desktop applications, without those applications being installed immediately to the FreeBSD laptop's root filesystem.

At "First boot," with the newly created Debian virtual guest machine, I installed the Debian package virtualbox-guest-dkms. To install the Debian package, I used aptitude package manager application on Debian. The selection is illustrated on an XFCE desktop, in the following screenshot.

After installing the virtualbox-guest-dkms package, I've then rebooted the Debian installation within the virtual guest machine. Following the reboot, the Debian installation can now utilize the VirtualBox Seamless display mode. Effectively, this allows for a close visual integration of desktop applications running directly in the Debian virtual guest machine, in a manner of visual integration with the FreeBSD desktop -- at which desktop, I've been applying the Cinnamon desktop environment.

Of course, the installation is not as functionally seamless as much as it may seem visually seamless, at least by the time of "Second boot". At time of "Second boot," I can't help but notice that the virtual host machine's mouse pointer is not actually producing input events to the desktop in the virtual guest machine. The host machine's mouse pointer then appearing to make a manner of geometry events, in the virtual guest machine -- at least, from how it seems, with the desktop of  the virtual guest machine being displayed within a VirtualBox window on the virtual host machine. It may be that the virtual guest machine is not receiving any input from the host machine's mouse pointer, in the "Second boot"

At "Second boot," the desktop of the virtual guest machine  has become unresponsive to the mouse pointer of the virtual host machine -- perhaps it may be something to do with the APIC implementation in the virtual guest machine, as I've not seen any such issue with the Microsoft Windows virtual guest machine I've installed on the same host machine. In retrospect, the "Unresponsive" state of the host machine's mouse pointer may have actually preceded the switch into Seamless mode in the display of the virtual guest machine. Perhaps it may be "Cleared up" with a simple reconfiguration of the respective VirtualBox virtual guest machine.

After shutting down the virtual guest machine in its minimal "Second boot" configuration, I've now reconfigured the virtual guest machine -- as such, within the host operating system -- such as to apply the original PIIX3 Chipset emulation within the virtual guest machine. Subsequently, I've booted to "Third boot." In a simple commentary, it may seem that the ICH9 Chipset emulation was sufficient for application at installation time, but that it's not working out as well, for application at normal desktop runtime. With the PIIX3 Chipset emulation again selected, then at "Third boot" of the virtual guest machine, again I'm able to use the host mouse pointer within the virtual guest machine.

The screenshot, above, illustrates the VirtualBox seamless desktop integration, with Debian 8.2 running  in a VirtualBox virtual guest machine, and the VirtualBox virtualization services then running on a FreeBSD host. On the FreeBSD host, I'm applying the Cinnamon desktop environment. In the virtual guest machine -- presently -- I'm applying the LXDE desktop environment. Though I'm considering to deactivate  the desktop environment, entirely -- albeit, then to a loss of "Window switching" behaviors in the virtual guest machine -- personally, I think LXDE is a nice "Starting point" for interacting with the virtual guest machine via a desktop/menu graphical interface.

As illustrated in the previous screenshot, when the VirtualBox virtual guest machine's display window is active on the virtual host desktop environment, and the virtual guest machine display window is configured for VirtualBox Seamless display mode,  then the host machine displays the LXDE desktop environment effectively as a layer on top of the host machine's desktop.  Visually, the effect is as if the Debian LXDE installation was running immediately within the Cinnamon desktop on FreeBSD. (Ed. note: Effectively, that is a characteristic of the functional configuration, moreover, with the LXDE desktop running within VirtualBox -- the VirtualBox virutalization services then providing a manner of a "Middle services layer" in  running the Debian virtual guest machine, and VirtualBox running within a desktop on a FreeBSD host.)

There are a number of optimizations that may serve to produce an optimally running virtual desktop environment, of a Linux installation in VirtualBox -- for instance, to adjust the "clock" timer in the Linux kernel configuration to a value that may be more optimal than the default value, such as for running a Linux desktop within a VirtualBox virtual guest machine. Furthermore, it may be advisable to disable the screensaver in the virtual guest machine. To any further detail, such optimizations will be left as an exercise for another article.

By time of "Fourth boot," hopefully my own simple CorvidCube will have the Evernote and Mendeley desktop applications installed. Presently, perhaps it's an -- albeit wordy -- "Howto" towards a configuration of a sort of meta-development environment on a desktop PC.

Ed. Note: As it turns out, the Evernote desktop application is not available for Linux platforms. Mendeley is, though [Download Mendeley Desktop for Linux]. Bibliography, and so on....

Concerning the Importance of /boot/loader for Grub2 configuration onto FreeBSD

A rhetorical question: How could it be a superbly difficult thing, to maintain a bootloader on a conventional BIOS/MBR-format hard disk drive?

I have an older laptop, which I'm applying as a network gateway appliance on a small, local area network. The laptop has three primary operating systems installed on its internal hard disk drive: The Microsoft Windows 7 operating system; Debian 8 (Jessie); a FreeBSD 10.1-STABLE source tree, updated and compiled on 18 June of this year. As of earlier this month -- contingent around what was the first time I've installed FreeBSD "Bare metal" to a laptop -- the FreeBSD operating system is now that laptop's primary operating system. This evening, I've finally figured out something of a kludge for loading FreeBSD via its boot loader -- having learned something more, it seems, about why the /boot/loader.conf file was not being loaded, previously. Though it is rather an awful kludge, but it's likewise a functionally working kludge, for the time being.

To update the boot loader for the FreeBSD installation on the laptop -- I've named it sol, figuratively --- I've now had to boot from a copy of the System Rescue CD, then mounting the partition of laptop's Debian installation, then performing a chroot to the mount point, then running grub-install and, for good measure, update-grub from there. Contrary to some earlier advice I've read, this evening I've learned that -- apparently -- I need to reference the FreeBSD installation's actual /boot/loader from within the Grub configuration file, itself.  It seems that without that, the /boot/loader.conf was being skipped, entirely.

As far as how to reference /boot/loader from within the Grub configuration file, and the FreeBSD kernel likewise, apparently that's the next tricky part -- in so much of guessing it out. Though I am certainly not certain of whether I've really guessed out all of how make a complete working Grub2 configuration for the FreeBSD installation, so far, but the following Grub2 configuration seems to suffice for it, for now:

menuentry "FreeBSD" --class freebsd --class bsd --class os {
  insmod ufs2
  insmod bsd
  search --no-floppy --set=root --file /boot/loader

  kfreebsd_loadenv /boot/device.hints
  kfreebsd /boot/loader
  #  kfreebsd /boot/kernel/kernel # ?

}

With System Rescue CD booted, the Debian installation's root partition mounted, and the shell running in chroot at its mount point, I've manually modified the chroot's /boot/grub/grub.cfg and then ran grub-install manually, virtually from Debian . I followed that with grub-update, for good measure. On rebooting, I was able to boot to the ordinary FreeBSD boot loader -- as I'd seen something similar to when first installing FreeBSD to that PC. In that much, it seemed to be a relatively straightforward configuration, finally, however that was not without a momentary message from Grub2, such that seemed to suggest as though I should load the kernel first?

Whatever was the cause of that momentary message, it disappeared quickly as the bootstrapping process was then handed over to FreeBSD. The FreeBSD boot loader menu was displayed, there presenting the opportunity to boot into multi-user mode or single-user mode, immediately. I booted into multi-user mode. After the operating system environment was fully initialized, I then logged in to the host. I was then able to verify that, finally, /boot/loader.conf had been loaded. There's a particular load-time sysctl configuration property in the host's /boot/loader.conf which serves to verify that /boot/loader.conf has been loaded.

net.inet.tcp.hostcache.cachelimit="0"

When /boot/loader.conf has not been loaded, the value of the sysctl parameter, net.inet.tcp.hostcache.cachelimit, is non-zero.

At last, hoewver, that value is being set to the value specified in /boot/loader.conf. Hopefully, the host will be performing more effectively as a LAN gateway now. Perhaps the reference to the FreeBSD installation's /boot/loader in the Grub 2 configuration may be a necessary feature of the Grub2 configuration, as in order for /boot/loader.conf to be processed during FreeBSD boostrapping?  Short or reviewing the source code of the Grub kfreebsd module, itself, I'll presume that that assumption might be accurate. Presently, it seems to me that the configuration "Works as intended," at least insofar as FreeBSD being boostrapped to the PC, and /boot/loader.conf being processed at boot time.

There was some advice I had read from a forum article, previously, which had omitted the configuration directive referencing /boot/loader for the Grub2 kfreebsd module to load FreeBSD. Concerning how the host was booting to FreeBSD without the /boot/loader directive in place, I was perplexed that /boot/loader.conf was then being ignored entirely.

Presently, I hope that I may ever be able to figure out how to configure Grub2 from FreeBSD, such that I should not have to boot to System Rescue CD in order to modify the Grub2 bootlloader configuration and it work as intended -- moreover, such that in the FreeBSD Grub2 installation, that the Grub2 configurator might locate every root operating system partition on that laptop's hard disk drive, and to permit that any of those single partitions may be booted to, with all of the configuration being developed in the FreeBSD installation. Perhaps I might be able to make reference to the Debian 8 Grub2 distribution, in the process of figuring that out -- if not, alternately, if there is a Grub2 distsribution for the Debian GNU/kFreeBSD operating system, horrid thing that it may sound like as a brand name.

The Grub2 distribution in Debian is stocked with a great, helpful number of Grub configuration scripts. Of course, the configuration scripts in the Debian 8 Grub2 distribution might not all be instantly applicable on a FreeBSD host -- there being any number of substantial differences between the GNU Linux and FreeBSD operating system kernels, such as with regards to filesystem interfaces and concepts of filesytem geometry..

Insofar as that FreeBSD is built with its own bootloader/installer, but in a plain sense, when I'd been trying to use FreeBSD boot0cfg as a bootloader on the sol  host, I'd been unable to boot to the host's partition number 7 -- it being a logical partition, effectively contained within an MS-DOS LBA partition. However, with Grub2 installed and managed albeit under another operating system on the sol host, but -- to a result -- I can now boot the PC to the FreeBSD bootloader. Candidly, it's an awkward kludge, as to how that's being managed on the host. Presently, it seems to function well enough for the simple LAN gateway host to function in all of how it is configured to function as a LAN gateway host.

At a future time, perhaps the LAN gateway PC an be replaced with a smaller BeagleBone Black single board computer. That, in itself, might require a substantial architecture so far as networked filesystems and PXE services, however, moreover with some odd kludging around about -- or rather, with some further review of the software source code of the U-Boot bootloader, as may be applied in any FreeBSD images build with Crochet, for BeagleBone, Chromebook, or other "cupboard size" computing platforms.

Presently, the LAN gateway role is kept by an old Toshiba laptop implementing an amd64 archicture. So to speak: #IWFM #YMMV

Ed. Note: In a theme of, "Correlation does not imply causality", hypothetically it may be possible that my present Grub2 configuration might not, itself, cause /boot/loader.conf to be evaluated by the FreeBSD boot loader, if the latter effect may be a side-effect of some other nondeterministic result of the configuration, as indicated. It may be possible to develop a further, exact understanding of the matter, with review of the Grub2 source code -- focusing, at least partly, about the kfreebsd Grub2 configuraiton command -- and the source code of the FreeBSD boot0 and later FreeBSD bootloader elements.

Presently, the author hopes to design a SysML sequence diagram indicating simply the state transitions of a "normal" boot0 bootstrap process, "In itself," though at the time of this Ed. Note, the author is furthermore trying to read up about Mozilla Gecko --  concerning the Document Object Model (DOM) implementation in the latter, the Gecko HTML rendering facilities, and the possibility of automating Gecko, securely, via a a CORBA process for ad hoc HTML rendering with or without an HTTP application layer protocol.


Partial Bibliography

• Unix & Linux Stack Exchange. How do you dual boot Debian and FreeBSD using GRUB2?
• Unix & Linux Stack Exchange. Set up Grub2 to boot Freebsd using either Ubuntu tools or LiveUSB to find what partitions?
• Leah Hanson. Notes on Installing and Booting FreeBSD from Grub2
• FreeBSD Forums. FreeBSD accessed via grub2
• Ubuntu Community Help Wiki. Grub 2 Other OS
• GeodSoft. Dual and Multi Booting FreeBSD, Linux, and OpenBSD
• Jakub Stolarski. Disable Slice in FreeBSD

Notes - Towards an Eclipse Kepler Distribution in Debian Packages, a Domain Model for Computer Operating Systms, and CCL for FIrefox OS

At a time earlier, this week, I'd installed Eclipse IDE via the Ubuntu 12.04 "Precise" package repository,  under the chroot environment installed on my Samsung Chromebook, which runs Linux on an ARM architecture -- as I'd noted in a blog entry, along with a convenient Eclipse platform versions/names table excerpted from Wikipedia, the Free Encyclopedia
My having observed that the Eclipse IDE, in its version as available via the Ubuntu package repository --  correspondingly, via the Debian source package, eclipse -- that it is not the latest release version of the Eclipse IDE, moreover that that entails that some plugins such as of the Eclipse Papyrus modeling tools project will not be available to the user, in their newest versions, when  installing the Eclipse IDE via the Ubuntu package repository, I've begun looking into the question: How to build Eclipse 4.3, "Kepler", for Ubuntu on Linux ARM?

Of course, although a Linux ARM build of the Eclipse IDE is available via both Debian and Ubuntu, however the Eclipse.org web site does not provide an Eclipse build for that architecture. Eclipse.org does provide downloads compiled for Linux x86, in 32 bit and 64 bit architectures, but nothing for running the Eclipse platform on ARM.

The Debian source package, eclipse, publishes a convenient Git repository, in a sense of both browsable (HTTP) and cloneable (GIT URI) repository services. There's also a convenient, moreover exhaustive list of build dependencies, published at the page for the Debian source package, eclipse. So, with that great level of developer convenience being available, about the Debian eclipse source package, and with my being interested in effectively updating the Debian eclipse source package to provide Eclipse 4.3 -- at least, in a local prototype build --  I've cloned the Git repository for the Debian eclipse source package.

When taking a look at files under the 'debian/' directory of the cloned source tree, I've found the file, 'debian/README.Source', in which some core features of the architecture of the source package are described, including:

• The Eclipse Build component of the Eclipse Linux Tools project
• A platform source archive, eclipse-${VERSION}-src.tar.bz2

Alternately, one may follow the Eclipse Linux Tools Project' Eclipse Build instructions unadordned, to the latest Eclipse source code, on ARM, albeit without the additional Debian packaging for redistribution -- substituting a Debian package dependency management command line tool such as aptititude instead of yum.

.... and that would be fine, except for the dependency on Jetty. Ubuntu 12.04 "Precise" does not provide a jetty-server.jar file. There is, however, a jetty8-server.jar available in the libjetty8-java package, in the "Trusty" edition (file list)

So, for backporting Jetty 8.1 from "Trusty" to "Precise" (source-package jetty8, "Trusty" edition) some of the build dependencies for jetty8 must also be backported from "Trusty", namely:

• libgnumail-java (>= 1.1.2-7) source package libgnumail-java
• libtomcat7-java (>= 7.0.28) source package tomcat7 
• glassfish-jmac-api (>= 1:2.1.1-b31g-2) source package glassfish

Of course, one might expect that a backport of each of Apache Tomcat 7 and Glassfish  might require, in each, a further set of additional backport builds. 

Failing the availability of a an ARM port of "Trusty", this would be one approach towards building Eclipse 4.2 "Kepler" on the Ubuntu "Presice" release, in the ARM architecture of that release of the Ubuntu GNU/Linux distribution.

Towards a Domain Model for Operating Systems and OS Distros

This backporting task, it may be further facilitated with the development of some additional software tools. Specifically, if developing a Common Lisp program to facilitate this package backporting process, one could begin by developing an abstract domain model out of this generic software task, in Common Lisp, such as:

• Class: Architecture
• Class: Release
• Class: Distribution

One could then extend that abstract domain model into an instance-specific model, such as for an application of that msamodel onto the Ubuntu GNU/Linux distribution. Of course, one might be aware of that the Ubuntu GNU/Linux distribution derives from the Debian GNU/Linux distribution, and uses the same essential software dependency management and software distribution tools, in the same as Debian GNU/Linux and most distributions deriving from Debian. 

That would be to the definition of a toolchain disjunct to that of the Red Hat and Fedora GNU/Linux distributions -- such as  Red Hat's commercially-supported enterprise edition distros like RHEL, or a Fedora Spin distribution, such as the Fedora Electronics Lab.

In a modeling sense, one may define the domain model such that the class, "Linux Distro" would be defined as to extend "Distribution", a class, and that each of "Redhat Distro" and "Debian Distro" would be defined as to extend the class, "Linux Distro".  

Subset of Domain Model: Non-Linux RTOS Distros

Furthermore, though it might diverge from the set of operating system platforms ostensibly compatible with the Debian Free Software Guidelines (DFSG) in any core portion, one could consider defining a class, "QNXNeutrino" as an extension of the class, "Distribution," as when the class "Distribution" would represent a broad sense of an "Operating System Distribution", if not specifically "Realtime Operating System (RTOS)  Distribution". 

In the RTOS domain, there's also FreeRTOS, itself a free/open source platform with commercial support available (summary of FreeRTOS licensing)

RTOS Linux

Sure, it may be viable to apply Linux as an RTOS. However, it might yet be difficult to find exact commercial support for RTOS applications of Linux. Certainly, there's commercial support available for Linux in server applications, and for Linux in desktop applications. However, as far as Linux in industrial automation systems, automotive passenger device systems, and other ostensible applications for RTOS frameworks, one might wonder if there is any commercial support available for such application, of Linux "as yet." In conducting one's research, then, one might find that there are a number of inactive projects for RTOS Linux, including:

• Real Time Linux Foundation, Inc.
• RTLinux
• uClinux (tm)

In a contemporary regards, there's Xenomai and the corresponding RTAI interface for timing-restricted applications, ostensibly with an XML-based server/RPC compliment, RTAI-XML, perhaps as an alternative to Realtime CORBA.

So, indeed, there's RTOS support of a kind, available for applications of the Linux platform. Sure, it might not meet with the most immediate demands of the world's boldest Ringworld engineers -- with apologies to fans of Larry Niven. However, with some patience and effort, it could turn out to be all of a commercially viable RTOS platform -- among things that one would not be able to add to a formal academic thesis.

Subset of Domain Model: Lisp Machine Operating Systems

Sidebar: Common Lisp is not BASIC is not a Horse Race

The reader might not be familiar with the author's position about the Common Lisp platform. Sure, in a personal regards, it's been nothing short of a long, rough road to the author, in studying the Common Lisp programming language and its applications, thus far, and certainly it's a none too commercially common platform, in the industry of the epoch. As a programming language, Common Lisp is certainly a more developed programming language than BASIC, though. For instance, the BASIC language -- at least in its Tandy Color Computer 3 edition -- doesn't feature, in itself, any sort of an object-oriented programming model such as in ANSI Common Lisp (CLtL2), let alone anything to compare to the full metaobject protocol (MOP) in Common Lisp. GOSUB is still pretty cool, though, at least for "that kind of software programming" -- such as of virtual horse races on a console screen, or a financial break-even analysis for a small/home office, and so on, mechanically.

The reader would be even less likely to have been familiar with either of the author's grandfathers. Some things would go unknown, in life, for a period of time.

'Boston Beans', the Gazebo Hub Lisp History Project Edition 1

If every project needs a novel name to denote it by, I'd choose a practical name for the beginning of a history of the Common Lisp programming language and its implementation in computing machines -- nothing too ostentatious, a humble can of Boston Baked Beans, the inspiration (via Amazon.com Prime Pantry, in a pinch.)

So, then, but how does one set out, practically, to begin to define a history of the Common Lisp programming language and its applications in computing machines? Would it require anything short of the expeditious skill of the discoverers of the Elephant computer, if not  the mathematical and mechanical skills of her original engineers? (Heritage Universe, Wikipedia) 

Sure, a can of baked beans suffices, in such an extensive endeavor -- nutritious food, sugary but kind, good foodstuff extended with a few items of bread, beside.

To begin to define a model subset of an Operating Systems model, for Lisp Operating Systems, one might begin at such a practical beginning as one would know, and by that I am referring to a private, ongoing study -- albeit, a study of only some few months' duration, "thus far" -- of the design of the CADR Lisp Machine.

Though the author of this item understand that CADR was neither the first nor the ultimate Lisp Machine -- in itself, was preceded by the CONS Lisp Machine, and succeeded by the Symbolics Lisp Machines -- there is simply the practical concern that there are schematics and manuals available, all of legally and ethically, as public domain resources -- books detailing the design and operations of the CADR Lisp Machine and its corresponding operating system, items originally published by MIT's AI Lab. Ostensibly, those same schematics could be studied and redesigned for application in developing a Lisp Machine prototype onto an FPGA platform -- as whether or not one may  have applied oneself to schoolwork and furthermore, well enough for one to be a student of MIT, as the author of this item is not, albeit with regrets.

In that much, such a study would not serve to explain any of how a contemporary Common Lisp implementation may be effectively interfaced with a contemporary host operating system, such as Debian GNU Linux. In a senser, there might even be a sort of "Crossover" determined between definitions of "Lisp Implementation" and "Operating system", in which the original Lisp Machines would have provided both "Lisp Implementation" and "Operating System," in any single, complete "software package," as one might presume.

Of course, a history of Common Lisp might represent likewise a history of software, hardware, and engineering, so far as conducted to the development of Lisp Machines and Lisp programming platforms with, in each, a user interface of some kind.

That, in itself, might not insomuch represent a history of the development of multi-user networked operating systems and industry specifications such as POSIX and the X/Open Portability Guide (XPG). Sure, it's not a monopoly, computer history, whether by way of Lisp Machine, or CP/M, or UNIX, or NeXT, or otherwise.

...and sure, there is history in computing, and there are contemporary models, in computing. It's unlikely that the later could have developed without the former -- it being not like any matter of the lucky turnip or the spontaneous "theory" undeveloped of practical application. One might choose to study either and both, then, in developing a contemporary application of computing, in a generic sense. Alternately, one might wonder: Of whence would new applications be developed, except of existing work?

Towards a "State" of the Turnip - Principia "Turnip" Milestone

Sidebar untold, momentarily: The Principia Project, and the Gazebo Hub.

With regards to the question of "Existing work," but presently, leaving aside the epistemological discussion with regards to patent guidelines -- i.e patent laws -- such as might exist in any single world nation of somesuch commercial development, there's still the question of how to define a subset of a model for operating systems, if specifically about Lisp Operating Systems -- considering not only that the history of Lisp Machines might be scarcely known, in the contemporary industry, but furthermore that there may be a hybrid model defined, of a Lisp/Linux system. Certainly, the a project for development of a hybrid Lisp/Linux system, such a projecxt could be conducted towards a more immediate commercial interest, in contemporary computer platform development, broadly, "The Industry." If it could seem to be a platform seeking of a sense of relevance for popular interest, one could sketch out a few ideas, at that -- all of which might seem more geared toward crowdsourcing than towards any manner of a conventional corporate model:

• At a server tier: Definition of a parallel computing model for parallel logical and statistical calculations onto the Amazon Elastic Compute Cloud (EC2) and affiliated components published by Amazon Web Services (AWS), using Lisp on Linux
• At a desktop tier: Definition of a data flow model  for Common Lisp programs, and a corresponding graphical interface, inspired by National Insturments (NI) LabVIEW(TM), using Lisp on Linux, with extensions specifically for using interfaces available in single-board computing platforms such as BeagleBone Black and  the PRU-ICSS  module in the TI Sitara MCU on the BeagleBone Black, for data-flow programming onto I2C device networks, inspired by NI LabVIEW(TM). 
• At a device tier, in a long term effort: The lovely project of transcribing the CADR schematics into an EDA format, revising that same schematic for a single device platform's memory, clock, and other interfaces, ostensibly using the Papilio FPGA platform, and then implementing something like a Lisp operating system onto that same platform (viability unknown). 
• Alternately, at a device tier, for defining a further computing platform, though without designing a "new OS", initially: Linux as RTOS, and Lisp, "Various projects", many of which might be ad hoc, in a sense, no doubt (recommended focuses: CORBA, I2C, parallel computing, ostensibly towards the definition of a realtime computing supercluster using Linux and single board computers having  I2C interfaces). See also: Liu, B., Y. Wen, F. Liu, Y. Ahn, and A. Cheng. "EcoMobile: Energy-aware Real-time Framework for Multicore Mobile Systems." (2011).
• Alternately, at a device tier, using only existing computing platforms without further interfaces and extensions: An investigative study of Clozure Common Lisp (CCL) and McCLIM extended for Cairo on the FirefoxOS platform. See also:
• Palladino, Valentina. Mozilla is testing the first Firefox OS tablet prototype. The Verge (2014)
• Firefox OS articles at the Mozilla Hacks weblog
• Context: Towards porting CCL to Firefox OS
• Firefox OS Architecture
• Firefox OS Apps Architecture
• Firefox b2g source code (Boot to Gecko)
• Gonk, effectively the OS kernel of the Firefox OS - based on Linux
• Note: B2G config.sh, emulator* device types
• See also: Previous notes and existing work, with regards to optimal functionality of RTOS systems including Linux
• Firefox OS System App
• Mozilla NSPR source code (???)
• Context: Towards extending McCLIM on Firefox OS
• Free/open source Cairo graphics toolkit, and language bindings -- focusing on the Cairo toolkit, if possible avoiding the Firefox middle-layer, for UI development using McCLIM in CCL on any single hardware platform or emulator, Firefox OS
• Mozilla2:GFXEvolution, esp. noting Mozilla Thebes interface for Cairo
• Mozilla GFX source code (with cross references), and corresponding top-level Mozilla Source Code Directory Structure (informative)

(This is 'blog entry draft 6, 2 June 2014)