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:
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.
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:
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.
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.
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?
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:
(This is 'blog entry draft 6, 2 June 2014)
.... 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
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:
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)
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,
- 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)
No comments:
Post a Comment