Month: January 2016

About Modeling of Software Components and Software Systems

Component architectures abound, in and among computing systems – whether as fine-grained as of individual component models defined in any single hardware definition language (HDL) such as VHDL, Verilog, and SystemC, or as abstract as any single logical platform model such that may be defined with MARTE or AADL, or as broad as any single software component model – such as of any single software component model defined in a single programming language, as in reference to Maven Artifacts, Ruby Gems, and PERL Modules, or defined in any single software distribution framework such as with Debian packages, the Redhat Package Manager (RPM), FreeBSD ports, or pkgsrc ports.

Theoretically, a single logical model can be developed as for applications in modeling of component architectures in a context of computing, such that the logical model would be applicable across those domains of application – respectively, (1) hardware definition languages and correspondingly, design verification tools, (2) logical computer platform models, and (3) software component models. In a practical sense, a logical model already exists, such that may be applied in such a context – as in reference to the Metaobject Framework (MOF) as MOF comprising a meta-metamodel, terminologically, and the Unified Modeling Language (UML) metamodel, as well as the Systems Modeling Language (SysML) metamodel, and other formal, normative metamodels principally defined as applications of MOF in individual domains of application. Specifically, the metamodel comprising SysML – including, as it happens to be, including components that are defined of the UML metamodel, and applied in SysML – the SysML metamodel may be extended with UML model profiles, alternate to defining any single “New” metamodel in extension to MOF. Such definition may be developed as proceeding to an application with regards to documentation of component architectures, and presentation of component architectures within platform design tools.

In a manner of semantic sense, as UML and SyML both representing applications of MOF, the relation of the respective UML and SysML metamodels as being orthogonal to the MOF meta-metamodel may be explained – with analogy – as in regards to definitions of classes as objects in a Common Lisp software program. Such explanation may make reference to the Metobject Protocol (MOP) as defined as an extension of ANSI Common Lisp (ANSI CL) – sometimes referred to as Common Lisp the Language, 2nd Edition (CLtL2) as with regards to set of data types, functions, procedures, and portable conventions defined of the numerous items of documentation comprising the effective ANSI Common Lisp standard. In a practical sense: A Common Lisp Standard Class may be defined as an instance of a Common Lisp metaclass, such that the respective metaclass is defined as a Common Lisp Standard Class, in itself. Effectively, if a Common Lisp standard class ‘B’ is defined as the definition of ‘B’ having a metaclass ‘A’, then the class ‘B’ – in a sense of a class definition – represents an instance of a class definition ‘A’. Effectively, this extends of the logical model in Common Lisp, in which class definitions themselves are represented as first class objects.

In a practical manner, the Class-Metaclass relation in ANSI Common Lisp may be denoted as representing a manner of a logical relation, such that provides a manner of consistency – if not portability, moreover – to Common Lisp applications defined in a context of the Common Lisp Object System (CLOS).

The logical relation of the Class-Metaclass relation in ANSI Common Lisp – often denoted as a metacircular relation – it may be addressed to applications, often, in applying a formal extension to the ANSI Common Lisp specification – most often, in application of the extension comprising the Metobject Protocol (MOP). The Common Lisp MOP was described originally in a commercially published text, the Art of the Metaobject Protocol (AMOP). The formal reference sections of the AMOP text have been published by the original authors, and are available as published by the Association of Lisp Users (ALU) in the text, The Common Lisp Object System MetaObject Protocol.

Of course, in a manner logically orthogonal to CLOS and MOP, some alternate object systems have been defined in Common Lisp programming systems – such with a reference to the Knowledge Representation (KR) schema object system developed in Garnet – technically, KR being defined at a “low level” in an application of Common Lisp ‘struct’ classes – and the object system effectively defined of the STELLA language, the latter as representing a manner of a language for Knowledge Interchange Format (KIF) developed in PowerLoom. STELLA, itself, may be transformed to source code in C++, Java, and Common Lisp, the respective source forms compiled in any single , standard toolchain to the respective programming language. The STELLA transformation engine, itself, is developed in Common Lisp.

As a manner of a technical sidebar: the PowerLoom open source codebase has been forked by the author of this article, in a project that may be denoted unambiguously as GraniteLoom. The GraniteLoom fork has begun with developing a manner of a portable system definition for PowerLoom, in application of the ASDF system definition facility as defined also in Common Lisp.

With regards to definitions of logical modeling languages, the MOF meta-metamodel – including, as it does, some “Low level” features of UML – MOF represents essentially a logical baseline for domain-specific metamodels. Each respective metamodel, likewise, represents a manner of a domain-specific logical vocabulary for modeling. Each metamodel may be applied, in turn, in developing any single, essentially application-specific model. Each application-specific model, furthermore, may be applied to an effect of “Instance data.”

In a practical manner, the MOF meta-metamodel in itself is encoded formally in an application of the XML Model Interchange format (XMI). XMI extends logically of the XML Schema Document (XSD) specification, applying some conventions developed in the XSD specification, furthermore logically extending of the set of data types defined in the XSD specification.

XMI likewise is typically applied as an encoding format for models developed in the Eclipse Modeling Framework (EMF) ECore metamodel.

For all of the diversity of kinds of modelling language, simply in applications of system modeling tools – beside the diversity of kinds of object system, as defined in individual software programming languages – certainly it may serve to recall the popular “Turing Completeness” theory. In a logical manner, it may hold true that any single “Turing complete” logical model expressed in a single syntax M may be transformed to a model of a syntax N, if M and N, both, are “Turing Complete” modeling languages. Of course, insofar as that a concept of “Turing Completeness” is defined typically in a context of logical estimates of “Computability,” it might seem like a “Bit of a stretch,” to suggest that the concept could be applied also about concepts of “Computer systems modeling.”

Principally, the question of whether a software program represents simply a model of computing will be left as an exercise for some later application – not to suggest as though it would be an arbitrary thesis, simply that it may seem be more of a philosophical question than a practical matter, in some regards. If a concept of “Turing Completeness” may be denoted, logically, as it being a concept applicable about any single modeling language – likewise, perhaps more of a philosophical concept than a practical thesis, per se.

Inasmuch as that the set of MOF and UML data type definitions, regarded together, may represent a manner of a comprehensive modeling framework, it is not necessarily to say whether MOF and UML are or are not “Turing Complete,” as modeling languages. Certainly, neither of MOF nor UML is expressly a functional language – rather more like a description language, in each.

In a broadest sense: If a software definition model may be defined as for an application in modeling of software ports, it may or may not be defined, simultaneously, for a purpose of marketing – whether socially or commercially.

Java on FreeBSD – Notes

Port exists: java/javavmwrapper
Java Option available w/ GCC ‘make config’ – cf. GNU Compiler for Java (GCJ)
OpenJDK – JDK + JRE + Tools Distributions – Ports
- OpenJDK 6: java/bootstrap-openjdk, java/openjdk6
- OpenJDK 7: java/openjdk7
- OpenJDK 8:java/openjdk8
Server VM performance monitoring, performance profiling: TBD\
Host Features
- fdescfs
  - fdescfs(5) [Manual Page]
- procfs
  - procfs(5) [Manual Page]
- devfs
  - devfs(5) [Manual Page]
  - devfs(8) [Manual Page]

Rudimentary CLI Dashboard for Poudriere – Console via ConnectBot SSH

With ‘mc’, reviewing log data after a build failure

GRANITELAN Wifi Bridging

Concept: wlan0 bridge to subnet on em0

Rationale (Overview) : Share subnet addressing between (1) effective network of appliances connected to wlan0 and (2) subnet of em0

Context notes:

em0 being an Ethernet network interface for network services to a SOHO LAN subnet – services including NFS for SOHO LAN, SSH for SOHO gateway appliance management, HTTP proxy service, firewall to untrusted Internet, NAT to network bridge on tap0
interface bridging as an effective alternative to network address translation for network interfaces to network appliances providing packet routing services on local subnets
Concept: cross-media bridge routing for a single LAN subnet (network media kinds: 802.1X, Ethernet) with a single SOHO LAN subnet gateway appliance providing the network bridge service
network service discovery available on subnet networks
mDNS; avahi; {host}.local name-based addressing
DHCP services – dynamic host addressing – DHCP server configured as to bind to each individual network interface, providing addressing per subnet definitions in DHCP service configuration

Further article: TBD (Ports build proceeding on GRANITELAN)

Towards a Logical Model for Software Component Build Configuration

Not as though to propose any manner of a commodity approach with regards to operating systems development, but simply in an observation with regards to the semantics of developing a single FreeBSD distribution for a single local area network: For all of the many configuration options available across all of the many software ports available in a FreeBSD operating system, it can seem difficult to decide about which options to select, for any single ports build – and to decide so, without being completely arbitrary in the selection of configuration options.

In a practical sense, it may seem useful to propose that one would select only so many configuration options as would be required for any single application of the FreeBSD operating system – such as to develop, theoretically, a manner of a “Minimalist configuration,” such as may be sufficient for addressing any single number of usage requirements, in any single application of a set of FreeBSD ports.

If a single ports build is being developed for no too exacting set of usage requirements, it may seem that there may be some more leeway available than as with the hypothetical “Minimalist configuration,” such as – for example – in developing any single manner of a software development platform.

In either instance – hypothetically, as of the “Minimalist Configuration” or the “Development Configuration,” in any single hypothetical ports build – if it may not seem too excessively tedious, in ways, perhaps it may be beneficial as to endeavor to logically describe any set of configuration options, and why each configuration option has been selected for any single ports build.

In so much as to analyze a set of configuration options as would be available with any single software port – such as may be analyzed in a manner pursuant to a description of any single set of configuration selections – of course, it may be observed that each configuration option may not, in itself, represent an “Island of data.” Rather, each configuration option for any single software port may be presented as each configuration option representing a manner of linked datum, in a manner of a linked list, such as may be defined with regards to any single model of software features and of software dependencies.

Broadly, a manner of component oriented software architectural model may be developed of a single ports tree, if simply in analysis of individual configuration options not only as individual data, but as data furthermore entailing a manner of logical relations to other software ports within the single ports tree.

In a manner of a broader view than of the singular ports tree, the FreeBSD operating system provides a number of components immediately in the operating system’s base system, as well as providing a number of components immediately in the operating system’s kernel, and in the bootloader provided with the operating system. Theoretically, a comprehensive component oriented model may be developed, thus, as of the FreeBSD kernel, the FreeBSD base system userspace utilities, as well as any single selection of FreeBSD ports, FreeBSD port configuration options, and – furthermore – individual service configuration options, such as with regards to sysrc parameters and application-specific configuration data files. Hypothetically, such a model may be denoted as comprising an operating system configuration model.

In regards to the port configuration model, specifically, a manner of a dependency graph may be developed as to illustrate any port dependencies existing across a single build of a single ports tree.

As one of the small “Design challenges” that may be addressed in the development of any single port system configuration model – as in a manner that may be functionally previous to the model’s application, in any single user interface system – as firstly in developing a manner of a prototypical analysis method for port configuration, it may be observed that there are some port configuration options that will effectively change a port’s dependency graph when such “Integrated Configuration” options are selected for any single port build.

In some instances, such configuration options may be denoted as representing, logically, “Single Optional” features – such as to an effect of whether or not a specific dependency will be created of a singular port build – as would be contingent on the selection of such individual port configuration fields, such as for whether or not to include GSSAPI support in a build of the databases/sqlite3 port, for instance. In such instances, a specific component dependency relation may or may not be created with the individual port configuration option.

In some other instances – such as for when there may be a set of configuration options, with each option of the set creating a separate dependency, as when exactly one of the configuration options is to be selected in the port build configuration – such as with regards to iconv and sqlite – a component dependency will be created of the individual port build, in any single choice of a configuration option, excepting any instance of “None of the above”. Such exactly-one-dependency features may be described as comprising feature dependencies, in a sense – such that the reification of the software component feature dependency, would be specific to which option is selected of the individual option set. In some instances, a “None of the above” feature may be available of the option set, such as with regards to GSSAPI support in some individual port configurations.

In a practical regard, a component dependency graph may serve to provide a manner of a graphical illustration of logical component dependency relations within any single port build, for any single set of port configuration options. For ports providing numerous configuration options – such as, for instance, the graphviz port – perhaps a depedency graph could serve in a role of by-in-large simplifying the selection of a set of build-time configuration options from the set of available configuration options for each single port and each correlated component dependency.

Of course, it may seem like an excessively tedious matter to provide documentation about so much as a set of configuration options for a single port build. However, even in the simple tedium of such a documentation process, perhaps it may serve a useful end as towards preventing that the port configuration process would become in any ways an arbitrary manner of process.

Thus – although no single metamodel accompanies the present thesis article – this article may serve to present a thesis: That ostensibly, a metamodel may be developed for presentation of port configurations in the development of any single instance of a FreeBSD operating system, or other approximately similar BSD operating system.

XDG Utilities on FreeBSD – An Overview

The following article represents a manner of a short, informal reference about applications of the XDG specifications, annotated with reference to individual Frhttps://wordpress.com/post/hardpanmedia.wordpress.com/4029eeBSD ports. This informal reference endeavors to develop a concept of applications of XDG desktop specifications, broadly, with regards to the following concepts:

Common Interactive Desktop Applications
Menus (TO DO: Note in this article)
Data File Locations
Data Files
User Authentication Policy (TO DO: Note in this article)
Audio Event Notifications

Concept: Desktop Environment

Platform Modeling for FreeBSD Builds : CSCOPEDIR and Its Applications

Editor’s note: Article may be presently in a non-linear state of revision.

In reviewing the set of configuration options as may be available to a FreeBSD 'make buildword' software compiler session, this afternoon, having noticed the definitions of the following Makefile parameters in /usr/src/sys/Makefile, I thought it might be worth writing a short article about the same. Perhaps it could seem like a matter of making an excessive interpretation of a few small properties of software tools, but I believe it may merit a further study as in regards to concepts of software development – to observe the definitions and applications of even these two ostensibly simple Makefile parameters – for what the definitions of these parameters may serve to present as the definitions, themselves, comprising resources of a technical kind.

The parameters of reference in this article are defined in FreeBSD /usr/src/sys/Makefile. Specifically, this article denotes the following two Makefile parameters

CSCOPEDIR
CSCOPE_ARCHDIR

The author of the present article wishes to take care to note that the author of this present article – though not being an original author of those variable’s definitions – that the author of this present article considers that those definitions may represent a kind of discrete sense of knowledge.

Of course, considering that the author of the present article is not presently well familiar with any manner of C development tools, perhaps the author’s choice of terminology may seem a bit quizzical to some readers. Not as though to split hairs over a choice of lexical terms – so to speak – certainly, this may all seem much more trivial to anyone more familiar with C development tools.

Thus, perhaps it may be unlikely that any manner of a formal reference page would be defined about these individual Makefile parameters – unlikely, perhaps, though perhaps somehow informative to developers.

A manner of the author’s own ad hoc analysis follows, as with regards to a semantics of those respective Makefile parameters and possible applications in a context of logical systems modeling.

Modeling the Development Environment

Ed. Note: This section develops a thesis of a single Makefile.

In a functional regard, the first of those Makefile parameters is defined – as denoted in the Makefile – defined such that the parameter may be applied with the etags tool, such as for generating a TAGS file, as well as applied for generation of a cscope name file resource, i.e in generating the file /usr/src/sys/cscope.files and in subsequent application of the cscope tool – broadly, as could be in applications in a manner of source code review.

Tools – Availability

The cscope tool is available via the software port, devel/cscope.

The etags tool, similarly, is available in the software port, editors/emacs.

The Makefile also provides a recommendation with regards the devel/global port, such that – broadly – may be applied in a manner corresponding with the etags tool, in a reflective analysis of C source code definitions.

There is, fourthly, a reference to the albeit presently expired port textproc/glimpse, as a manner of a utility denoted in the same singular Makefile.

Modeling CSCOPEDIR

In a semantic regards, the definition of the CSCOPEDIR variable may be interpreted as that the filesystem directories denoted by the variable may be – in a sense – furthermore relevant, as with regards to semantic structure in the FreeBSD source files – if not moreover relevant as in regards to the design of the FreeBSD kernel and bootloader framework. Perhaps it could seem like a trivial topic, to some perspectives.

Orthogonally: If a manner of a modular, if not furthermore logical model may be developed about the definition and structure of the FreeBSD operating system source code, perhaps any number of descriptions about such a model may serve to aid in any number of roles with regards to FreeBSD operating systems development – such as with regards to documentation, tooling, and issue tracking. This present article, however, will not endeavor to advance any complete UML model for FreeBSD. This article, rather, will limit the discussion to a couple of properties with regards to platform definitions.

In that single Makefile definition, the definition of the CSCOPEDIR variable effectively subsumes the definition of the second variable, CSCOPE_ARCHDIR.

Modeling CSCOPE_ARCHDIR

On reviewing the contents of the single Makefile, it appears that the value of CSCOPE_ARCHDIR itself may be interpreted as denoting – in each value – a concept that could be denoted as of any single microprocessor architecture, such that may be defined as any single value of MACHINE_CPUARCH in a FreeBSD operating system build. Broadly, perhaps it may not be all of a trivial work, to model such configuration definitions with a MARTE diagram, but perhaps one may hope that it could ever appear to be trivial – such as with regards to any singular, if not formal concepts of definitions of microcontrollers, instruction set architectures, and broader computing platforms.

The definition of the CSCOPE_ARCHDIR variable may be interpreted as towards something of a further practical application, as with regards to definition and selection of machine platform architectures – such as when building a cross-compiler framework in an application of the FreeBSD operating system. There is the crochet project, for instance, providing – as in a sense of a logical model – a set of corresponding board definitions as well as providing a set of tools such as may be applied in building a FreeBSD distribution for any single mobile and/or embedded computing applications.

Of course, there’s also the release/picobsd source tree under /usr/src as well as – separately – the NanoBSD HOWTO, as corresponding with the tools/tools/nanobsd subdirectory under /usr/src Fourthly, there’s also mfsBSD, as a manner of a tool available for building software distribution images.

Modeling of a Data Definition Source

This article endeavors to make discrete reference to the individual source files in which the respective Makefile parameters are, each, defined. In a manner of consideration as with regards to development of logical, if not moreover functional software modeling tools, it may be appropriate to define a property, definition source, as when modeling any single software parameter definition such that the model definition would be derived directly in modeling of a variable definition in any single work of existing software.

In a semantic regards, such a convention might resemble the recording of the definition source property for macro definitions, function definitions, and variable definitions, as with regards to definition source properties produced in the CMU Common Lisp (CMUCL) compiler and correspondingly, in the fork of CMUCL comprising the contemporary SBCL project.

In a concern as with regards to UML model definitions, a definition source property may not, in itself, seem relevant for modeling within any single model class’ distinct attributes section – such that may be representative more bout applications of a definition of a model class, moreso than being representative of any single origins of a model class’ definition. So, to a model class definition for representing any single Makefile parameter – as within an application of a hypothetical Makefile profile for UML – perhaps a UML tagged value may be attached, as with a manner of a tag kind, definitionSource and a manner of a tag value representing a URI denoting a single source file in any single source code repository.

Of course, the hypothetical modeling tool could likewise be integrated with a single source code management tool, in such a way as may serve to facilitate a review of a single source code definition, across any multiple revisions of a single software codebase.

Modeling a Model Application

In a sense, this article nearly proposes a manner of a visual modeling tool for source code analysis in a desktop computing environment – such as in reference to the Eclipse Modeling Framework (EMF), if not moreover in reference to the Common Lisp Interface Manager (CLIM) specification.

For a single application in regards to source code modeling – such as for application in a practice of source code review, in a development project – hypothetically a CLIM application frame could be defined within a CLIM application – however, the rudimentary visual characteristics of a CLIM implementation could seem, perhaps, too rudimentary for it to become a popular thesis.

Ed. Note: In retrospect, it may seem to be “Much ado” about a small number of Makefile parameters. Perhaps it is not only about the Makefile parameters as data, however, neither as though exclusively about how those data are applied in the development toolchain.

Ed. Note: With regards to platform modeling for FreeBSD builds, the following Makefile parameters may be noted twoards more of an immediate sense of interest. The following Makefile parameters are defined in the FreeBSD source file, /usr/src/Makefile

Makefile parameters defining TARGET/TARGET_ARCH tuples – FreeBSD 10.2

TARGETS [Makefile Parameter]
TARGET_ARCHES_arm [Makefile Parameter]
- arm/arm
- arm/armeb
- arm/armv6
TARGET_ARCHES_mips [Makefile Parameter]
- mips/mips
- mips/mipsn32
- mips/mips64
- mips/mipsel
- mips/mips64el
TARGET_ARCHES_powerpc [Makefile Parameter]
- powerpc/powerpc
- powerpc/powerpc64
TARGET_ARCHES_pc98 [Makefile Parameter]
- pc98/pc98
- pc98/i386

Applications of the TARGET and TARGET_ARCH parameters are denoted in the build(7) manual page.

MOOCs in a Nutshell

What’s in a MOOC?

Forums
ePubs
Quizzes

Kind of high-maintenance,* isn’t it?

Examples of MOOCs**:

Concerning the topics of forums and ePubs in a service-oriented perspective, there’s a fairly broad range of existing works available – as in regards to software tools, if not in all ways with regards to learning methods, and furthermore, thesis manuscripts.

In regards to quizzes , specifically – broadly, as at a topic of approaches available to educators, available for “Verification of learning,” in a technical regards – there’s a nice and succinct article about LearnDash, published by DigiSavvy, the article, LearnDash Tutorial for Creating Courses and Selling Them with Easy Digital Downloads

In all of the Lively Internet of the contemporary era, the present article concludes with footnotes.

* Participation by experienced and knowledgeable educators may be what “Closes the gap” between “Resource” and “Knowledge,” in a MOOC learning environment – perhaps not all unlike in other educational settings.

** Avoiding any manner of a formal review of any formally accredited schools’ own ostensible e/learning platforms, if only to keep to a constructive theme about contemporary academia in contexts of technical engineering – there being not a whole lot of social ambiguity in I=E/R

PANOS Software Component Orchestration – Initial Thesis Article

Not to indulge idly about ambitious kinds of project – neither to reminisce at any too whistful excess, though wondering what climate it may have been, in which FreeBSD version one was created – presently, a simple sketch with regards to portability between NetBSD pksrc, FreeBSD ports, and Debian packages:

Makefiles
Configuration Parameters
Package Build Process

There are one or more exacting, logical models that may be produced about each of those three topics, applied in a context of each of NetBSD pkgsrc, FreeBSD ports, and Debian packages, such that a total of at least twelve individual modeling diagrams may be produced of any single, combined documentation project, to such effect:

An abstract model, such as – in this endeavor – such as may produce a set of logical diagrams about each of:
- Makefiles, in standard applications and standard locations
  - A significant feature on any BSD
  - With Debian packaging, mostly focusing on the conventional debian/rules makefile (GNU Make
- Configuration Parameters
  - A significant feature on any BSD – in which, any package build authority may assign any of an available set of configuration parameters to any single set of pacakges, such that may substantially affect not only the dependency graph of the resulting packages, but furthermore – to a practical userspace – may substantially affect the overall functionality available of the entire package distribution
  - Selected to a single configuration base, throughout Debian package distribution – there being not any “make configure” step during ‘debuild’
- Package Build Processes
  - Operated by way of a kind of Make in all three of the practical contexts denoted in this article – GNU Make, with Debian; FreeBSD’s current make, cf. pmake, fmake, others; NetBSD’s make, which might be manifest as nmake on FreeBSD
Abstract model, applied onto NetBSD pkgsrc
Abstract model, applied onto FreeBSD ports
Abstract model, applied onto Debian packages

There might be a further domain addressed of such a project, moreover, as to address any number of single usage cases, for instance:

HOWTO: Install the Debian EFL distribution on FreeBSD, NetBSD, within the set of operating systems in “Immediate focus” it the endeavor
HOWTO: Configure “the EFL build,” such as that it may more closely resemble the configuration interface available with both of FreeBSD and pkgsrc ports – assuming that the build manager person would be permitted to choose what configuration parameters to apply, in constructing the upstream software – observing, furthermore, how the broader BSD ports framework permits for such host-local configuration choices, effectively adapting the entire build process around individual configuration options, and significantly modeling the upstream software in a uniform configuration interface structured according to “Best common practice” and documented in such as the FreeBSD Porter’s Handbook, on FreeBSD
HOWTO: Port a “New” component to “The exiting codebase,” e.g. Garnet – with a “Side thesis” in regards to developing Common Lisp applications in the “Hybrid ports/package system,” such as of any as may be developed in a mashup of Debian packages, NetBSD pkgsrc, and FreeBSD ports
HOWTO: PKI, considering the substantial integration of X.509 certificate chains in conventional Debian package distributions – shoutout to Let’s Encrypt and also Netflix

Of course, to no small sense of chagrin, the author of this article is still uncertain of how best one may pragmatically address the following orthogonal usage cases:

HOWTO: Install DITA 1.2 doument schema, the DITA Open Toolkit, and DITA4Publishers, all “usefully” and “well,” on any single operating system – for any single set of concrete definitions of concepts of “usefully” and “well”
HOWTO: Apply DITA together with any existing data structure systems – such as PowerLoom KIF and/or any single RDF graph database system – as in a context of actual article data content – cf. HDF5 format, IVI in a context of VISA, and measurement tools in a context of electronics engineering – or in a context of bibliographical metadata, as data about articles
HOWTO: Graph all the things, and document the logical and mathematical derivations of all the things, and document any known open-access applications of all the things, when the proverbial Universe of all the things, as a metaphor, is limited to a set of concepts in regard to physics, mathematics, logic, electronics, communications, and computing
HOWTO: Present an ambitious project as in a manner of understanding, that it often may take not much of a sense of ambition to simply turn a wrench, metaphorically and/or literally
- …and then again, there is the Torque diagram
- …and of course there are all the small automation things, such as with regard to the historic Capsela brand name
HOWTO: Big media project, with all of the low-level “Fluff” – to so pretend of being casual about systems management – of a universe limited to:
- Caucho Resin, a Java application server
- Cauho Quercus, a PHP interpreter implemented in Java
- WordPress, a popular and widely supported web log service implemented in PHP
- …and all of the “Value added” development that one may produce to such an endeavor, e.g. with regards to
  - Java Content Repository (JCR) integration
  - CORBA FileService interfaces for client/server applications synchronizing media content – in a deterministic manner of process – across the proverbial S/WAN
  - Host-level services, such as Kerberos and FreeRadius
  - The PKI backbone it may apply
- …and all of the commercially licensed products that may be applied in such a project, e.g.
  - Macromedia … rather, Adobe Dreamweaver CS 5.5, whereas the author of this article has not “Moved on to CS 6”
  - OxygenXML, in as its presentation of DITA structures really “Makes sense,” after all
  - All of the commercially licensed mobile computing things, at the mobile computing layer – cf. Qualcom’s Snapdragon fork of LLVM; Samsung KNOX at not-the-server-side-albeit; proprietary schematic capture and FPGA platforms, in so much as of applications of physical sciences limited to a domain of electronics, if not broadly enough described that it might not become a target of any single “Patent Hunter,” so to speak

The figurative “part” of not being stymied of the ambitious nature of such projects, it might be difficult for the author to describe, at length. That we are proverbially living in a duration between the traditional aerospace of the Cold War and the privatized projects of the NewSpace economy, not in any ways does the novelty of it permit for any manner of a casual view about safety, however.

Thus, in like as with a long bicycle ride, perhaps one learns to not look too far ahead, while proceeding in a direction forwards.

This article denotes the first public announcement of the Hardpan PANOS project – developing a Platform Agnostic Network Operating System (PANOS) framework, towards applications on FreeBSD and other host operating systems.

On Studying the Fourier Series

In rounding out the first week of what will have been my final semester as a student of a certain online university, I’ve made a short study to understand the mathematical definitions and possible applications of Fourier Series, as might be applied principally in a context of signals analysis – if not furthermore applied as with regards to signals synthesis. I cannot conclude as if I have arrived at any exact association of concepts of frequency harmonics, partial differentials, and algebraic transformation of arithmetic series – though I had hoped to arrive at any more of a concrete sense of understanding about such topics, towards how such concepts may find any tangible applications in radio signaling systems, if not also towards applications specifically in regards to functional audio systems.

I have, at least, learned a few more things about mathematics, and math books.

First, there is a series of texts specifically about the Fourier Series

D, Robert T. An Introduction to Fourier Series and Integrals. Mineola, N.Y.: Dover, 2006. http://public.eblib.com/choice/publicfullrecord.aspx?p=1909782.

Gbur, Greg. “Fourier Series.” In Mathematical Methods for Optical Physics and Engineering. Cambridge ; New York: Cambridge University Press, 2011. https://www.safaribooksonline.com/library/view/mathematical-methods-for/9781139636049/.

Martin, B. R., and G. Shaw. “Series and Expansions.” In Mathematics for Physicists. Hoboken, New Jersey: John Wiley & Sons Inc, 2015. https://www.safaribooksonline.com/library/view/mathematics-for-physicists/9780470660232/c05.xhtml.

Smith, Steven W. “The Fourier Series.” In The Scientist and Engineer’s Guide to Digital Signal Processing, 1st ed. San Diego, Calif: California Technical Pub, 1997. http://www.dspguide.com/ch13/4.htm.

Secondly, there is a series of books about broader mathematics, and books with regards to applications of mathematics in modeling to the ideal domain in design and analysis of electrical systems:

Boggess, Albert, and Francis J. Narcowich. A First Course in Wavelets with Fourier Analysis. 2nd ed. Hoboken, N.J: John Wiley & Sons, 2009. https://www.safaribooksonline.com/library/view/a-first-course/9781118211151/.

Cucker, Felipe, and Society for the Foundation of Computational Mathematics, eds. Foundations of Computational Mathematics, Budapest 2011. London Mathematical Society Lecture Note Series 403. Cambridge ; New York: Cambridge University Press, 2013. https://www.safaribooksonline.com/library/view/foundations-of-computational/9781139611329/.

Davis, W. Alan. Radio Frequency Circuit Design, 2011. https://www.safaribooksonline.com/library/view/radio-frequency-circuit/9781118099476/.

Gbur, Greg. Mathematical Methods for Optical Physics and Engineering. Cambridge ; New York: Cambridge University Press, 2011. https://www.safaribooksonline.com/library/view/mathematical-methods-for/9781139636049/.

Kelley, W. Michael. The Humongous Book of Trigonometry Problems. New York: Alpha Books, 2012. https://www.safaribooksonline.com/library/view/a-first-course/9781118211151/.

Martin, B. R., and G. Shaw. Mathematics for Physicists. Hoboken, New Jersey: John Wiley & Sons Inc, 2015. https://www.safaribooksonline.com/library/view/mathematics-for-physicists/9780470660232/.

Niederreiter, Harald, and Gerhard Larcher, eds. Applied Algebra and Number Theory. Cambridge: Cambridge University Press, 2014. https://www.safaribooksonline.com/library/view/applied-algebra-and/9781316120552/.

O’Leary, Michael L. A First Course in Mathematical Logic and Set Theory. Hoboken, N.J: Wiley, 2016. https://www.safaribooksonline.com/library/view/a-first-course/9780470905883/.

Roy, Ranjan. Sources in the Development of Mathematics. Cambridge ; New York: Cambridge University Press, 2011. https://www.safaribooksonline.com/library/view/sources-in-the/9781139635516/.

Svoboda, James A., and Richard C. Dorf. Introduction to Electric Circuits. 9th edition. Hoboken, NJ: John Wiley and Sons, Inc, 2014. https://www.safaribooksonline.com/library/view/introduction-to-electric/9781118477502/.

Of course, all of this bibliographic study is very much facilitated with Zotero.

Lastly, a reference section of a manual about a certain, comprehensive computer algebra system (CAS) developed in Common Lisp, furthermore licensed and distributed as free/open source software (FOSS), i.e Maxima

“Maxima 5.36.0 Manual: 28. Sums, Products, and Series.” Accessed January 10, 2016. http://maxima.sourceforge.net/docs/manual/maxima_28.html.

Certainly, to share these references, it is not for any manner of a wont of spectacle. I may rather have a set of spectacles enough, candidly, in the inorganic subset of my four eyes.

Presently, this article is published in its first draft edition – the bibliography shared, and ready to publish for review by a million eyes, plus or minus a million.

Shortly before beginning this short (?) study, I had published the first of the Hardpan Media Open Book Projects, to GitHub: Electrical Engineering – Hardpan Media Library – Open Book Project

Basic Principles/Concepts Developed of Physical Sciences, i.e. Physics
Logic and Mathematics
Practical Applications in Electrical Engineering

I believe is is not comprehensive, at depth, as an outline. Neither would I wish for it to be mistaken as an encyclopedic presentation of concepts, candidly. It is simply a manner of a concrete topical taxonomy, not designed for the management of any single literary institution beyond my own one person’s small, individual efforts in technical study.

There are some updates that I would like to develop to its version 1.0.0, but it may seem to entail a too-far semantic stretch, to proceed – if in an immediately direct manner – if proceeding from “Computational Models” directly to “Operating Systems,” in any practical regards.

Secondly, I think that it needs for a manner of a practical integration between SKOS and data structures applied in the Zotero web service – at which, perhaps it could be towards an independent data management structure for Zotero bibliographic tags, if not a manner of a bridge from (1) Bibliographical content curation, content review, and formal study, to (2) Content Creation.

The “README” file for the Hardpan Media Library EE Open Book Project