OS Platform Compatibility, in a Laptop Recovery View - Filesystem Compatibility, Binary Incomptibility

Recently, my primary laptop became effectively bricked, insofar as booting from the laptop's internal hard drive and booting to the MS Windows 7 installation, on that laptop. It's a Toshiba model, an A665, with a thin form factor not affording much air circulation internal to the laptop. The laptop has a wide screen and a contemporary Nvidia graphics card. It has been my "main laptop," for a couple of years. Tasks that it is not bricked for would include:

•  Boot from external DVD drive or flash media
• Chroot to the Linux partition on the internal hard drive -- the SystemRescueCD can be used to manage the chroot environment of the same, for simple recovery tasks, albeit with some concerns as in regards to kernel compatibility and device creation under devfs
• Mount the Windows main partition or either of the recovery partitions on the internal hard drive

I've tried to fix the MBR on the internal hard drive, using TestDisk, such that is distributed on the SystemRescueCD. However, the laptop is still not bootable from its internal hard drive. I plan on holding onto the laptop nonetheless, until if I may be able to replace the internal hard drive with an internal SSD drive, and to re-image the "Good partitions" from the existing internal hard drive onto the ostensible SSD drive, certainly not carrying over any "Bad bits" from the MBR sector or however.

In short, I can boot the laptop from an external DVD drive, and can mount and chroot to the Linux partition on the laptop, and from there, I can mount the Windows partitions. It's fine for filesystem recovery, but with the internal hard drive in an unbootable condition, and with the recovery media unable to boot the existing Windows partition -- though it can mount the same --  to my observation, it's effectively "Nil" for running any of the Microsoft Windows software installed on the same.

I've reverted to an older laptop, an older Toshiba, such that has Windows Vista installed. That's been sufficient for running the software required for courses at DVUO, however I am certainly interested in rendering my "Main laptop" usable, again, at least on its Linux partition, and without the DVD dongle. It would serve at least as a cross-compiling platform for the ARM architecture.

As of when my "Main laptop" became unbootable, then my Chromebook became the effective "mainstay" for developing on Linux, on my "Home network." It's a Samsung Chromebook. Samsung Chromebooks use an ARM architecture -- I'd chosen the particular model of Chromebook, as due to that, when I purchased the Chromebook from BestBuy, on my student budget. I've since enabled Developer Mode on my Chromebook and installed a KDE desktop environment into a chroot, using Crouton, furthermore referencing a "How To" published by HowToGeek, How to Install Ubuntu Linux on Your Chromebook with Crouton.

The chroot environment on the laptop is using Ubuntu Linux, edition 12.04. "Precise". The Linux kernel is version 3.8.11, armv7l architecture.

To my understanding, QEmu is unable to create a VM on the ARM architecture. Virtualbox is not available for Linux ARM, either. Failing any other alternatives for OS virtualization on Linux ARM, my Chromebook therefore cannot serve as a virtualization host.

There are a number of software applications that I would prefer to use on my Chromebook -- including Modelio, and the latest edition of the Eclipse IDE -- but which are not immediately available on Linux ARM, and are available on amd64, such that is the architecture of the Linux installation on my main laptop. Given that my ARM chromebook cannot emulate an amd64 environment, not to my understanding, I shall have to either do without those applications, indefinitely -- an undesirable situation, certainly -- or I shall have to figure out how to recover my A665 laptop, at least so far as that it can boot without the "DVD dongle"

My A665 laptop can boot from USB. Of course, all that I need to have it boot from USB would be: The boot loader, ostensibly. There's already a working configuration of a Linux root partition and swap partition, accessible after boot, on the internal hard drive of the laptop. I might as well wish to install a minimal OS configuration onto the flash media, however -- something that could at least run a shell, in an event of that flash media being the only usable media in the laptop.

I've yet to find a "Pre-built" Linux USB thumb drive distro that would be clearly compatible with this particular use case -- basically, just an external, chained boot loader -- moreover in a minimal filesystem configuration.

This morning, I have begun to read up about Ubuntu Core, a minimal Linux distro.

If I was able to run a virtualization environment on my Chromebook, I could begin to configure a thumb drive for using Ubuntu Core, immediately, using chroot and/or QEmu. There would be a certain matter of "platform difference", as between the host platform and the target platform, however, when my Chromebook (ARM) is the host platform, and the A665 (amd64) is the target platform.


Here is a model for a Platform view of my own PC environment, expressed in a sort of ad hoc UML notation:

[Target Platform <<Platform>>]-*----+-[Filesystem]
  |
  |+
  |
  |
  |+
  |
[Host Platform <<Platform>>]-*----+-[Filesystem]

In the situation in which the Ubuntu chroot on my Chromebook (armv7l) would the ostensible "host platform," and the "target platform" is amd64, but the former is a host platform that is currently unable to run virtualization software, to my best understanding. The ARM and amd64 architectures would be  incompatible, moreover, as due to "something in regards to ABI,"broadly.

Effectively, an ARM Chromebook cannot serve as a complete host platform for building and testing of a recovery disk for an amd64 OS.

Of course, a host platform running an ARM Linux OS can be used to transfer a filesystem image to a storage device supported by the host platform, and can mount an EXT2 or later edition EXT_ filesystem from a supported storage device or, can mount a filesystem directly from a block device image -- like as in a manner of flesystem compatibility. However, if the target platform does not implement a processor architecture similar to that of the host platform, then the host platform cannot  effectively chroot to the target platform's root filesystem, as the machine-dependent files on the chroot 'target' would be binary incompatible with the machine architecture of the host platform.

In summary:

• ARM and AMD64 Architectures : Binary incompatible, in machine-dependent files
• EXT4 Filesystem: Compatible with any OS such as can mount an EXT2 or later EXT_ edition filesystem. Mounting an EXT4 filesystem as EXT2, of course, would entail a certain loss of features available in EXT4 (cf. filesystem journaling) for the duration of time in which the filesystem would be mounted, in the host OS.

In extension: Use cases for a dynamic host platform modeling interface

• Filesystem Imaging
• Integration with functional filesystem management tooling (favoring command-line tools)
• Cross-Compilation
• Integration with functional distribution management tooling (favoring command-line tools)
• Network Management
• Integration with functional user authentication interfaces (Kerberos, etc)
• Integration of network models (Ethernet/WLAN, IPv4 protocol stack, etc)
• Integration with networked host control interfaces
• SSH - Command line interface
• CORBA - Distributed network host management interface TBD

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)