Tuesday, June 30, 2015

IPF w/o SysML

After installing FreeBSD 10.1 to an older laptop -- effectively, in developing a LAN gateway appliance out of my older laptop PC, applying FreeBSD as an alternative to Debian 8, then hoping FreeBSD might be more predictable in terms of simple network performance, if not furthermore more interesting for installation onto an BeagleBone Black's ARM architecture -- I searched, early on, for documentation about how to configure the FreeBSD OS for network firewalling and network address translation (NAT). I found two articles about the topic, immediately, in the FreeBSD handbook -- specifically, section 30.4 IPFW, and section 30.5 IPFILTER (IPF).

As my being relatively more new to the structure and configurations of the FreeBSD base system, at that time, candidly I wasn't exactly certain of which firewall/NAT framework to apply, of those two available options.

To my point of view -- albeit, at the earlier time -- the documentation about IPFW seemed, I thought, more approachable. Though I wasn't particularly certain if I could learn to understand the semantics of either IPFW or IPF, immediately, but in beginning with the substantial examples provided in the IPFW documentation, I implemented a rudimentary NAT firewall on the LAN gateway. Subsequently, I installed DBJ DNS' dnscache and the Squid 3 HTTP proxy, also on the same low-load gateway. To this time, I've been able to make use of HTTP, SSH, and IRC services across the LAN gateway, in the latter's NAT configuration. However, I've been encountering a persistent issue with regards to FTP downloads across the gateway. Broadly, I believe it may have something to do with FTP operations in passive mode and the characteristics of the NAT configuration on the gateway host.. Although without drilling down on the documentation about the FTP protocol, personally I've decided to apply IPF as a firewall  instead.

Along with this small change in the host's architecture, furthermore after an initial review of the respective IPF section of the FreeBSD handbook, personally I would like to develop some further, small documentation about IPF, as in a sense of a SysML model about the IPF shell command interface and its functions in a network firewall architecture. Of course, this will require some amount of a tedious tooling around with a modeling platform of some kind -- for instance, Modelio or the Cubetto Toolset. I don't particularly imagine as if that could be quite a nice ordeal, any more, however -- considering  the nature of the entire gripey web, broadly, moreover considering so many of people's own inventive agendas, candidly, the inevitable "Web sharp shooters" so to speak, it really does not make any manner of an incentive for any good works whatsoever, when one cannot even begin an article ere it's shoved aside for someone's own pretentious whim, the commentariat in full swing.

Perhaps it reminds of a metaphor about fortress building games, if not furthermore a metaphor about utter childishness. By no means does it ever remind of a software development community.

Presuming that if I have seen it before -- a ridiculously biased comment for a simple article -- and it made no sense to me then, that therefore I must expect to see it again, if I ever dare to write again in the audience of the commentariat without respecting people's own sensitivities so far as I cannot even possibly guess -- taking such a matter to a certain conclusion, logical or not, common or not, it essentially halts all discussion, lest anyone have their feelings wounded on a bad day for it, by even an accidentally cheerful thing.

So, seriously, why bother to present anything cheerful, any more, to the commentariat webs?  Let the state of the art slide further into the dust bin of history, if there are simply too many too poignantly emotional agendas going around for any science to actually advance any further.

So, at some point, there might be a SysML model to show, but not here, and not today.

Monday, June 29, 2015

A Review of CLIM Presentation Types (Draft 5)

The Common Lisp Interface Manager specification, version 2 (CLIM 2) defines an architecture for an implementation-generic type system -- essentially. a type system orthogonal to the underlying Common Lisp Object System (CLOS) -- as namely, in the presentation types architecture defined in CLIM 2.

There might be a question that may occur, as in an inquisitively rhetorical manner, as to why the CLIM 2 presentation types system is defined in a manner essentially orthogonal CLOS, moreover independent of CLOS? One might speculate: At the time when CLIM 2 was developed as a specification, moreover at that time in the evolution of the Common Lisp software programming language, perhaps CLOS may not then have been regarded a it being a mature object system, sufficient for CLOS to be more thoroughly, if not singularly adopted for application in CLIM? Considering the development of the Metaobject Protocol (MOP) for CLOS implementation, in a sense of historic tiimelines, perhaps the development of the MOP specification and its subsequent publication -- that, as in The Art of the Metaobject Protocol (AMOP), also in the MOP implementation codified as PCL -- perhaps that may have served to lend more of a sense of codebase maturity for adoption of the CLOS specification.

Alternately, considering the syntax of CLIM 2 presentation type identities, perhaps a singularly CLOS-oriented architecture might not seem sufficient, without it being integrated with any number of implementation-specific details, as to the  nature of the implementation of the fundamental type system in any single Common Lisp implementation.

Inasmuch as CLIM may be furthermore adapted, if not centrally revised for alignment with CLOS and MOP, but of course such adaptations should be accompanied with some substantial documentation, as towards existing forms and adapted forms, and rationale, etc.

Reviewing a small number of albeit superficial qualities of the design of the CLIM presentation types system, one may arrive at any small number of observations. Towards developing an abstract model of CLIM, this article will make note of the following observations:

  • CLIM 2 specifies behaviors for definitions of presentation type, presentation generic functions, and presentation methods
  • The type identity of a presentation type may be specified with a syntax analogous to the syntax of conventional Common Lisp type specifiers.
    • An orthogonal observation: Some implementation-specific features may be developed in an implementation of CLIM, such that for dispatching in selection of any one or more CLIM type specifiers, for any single value, a manner of "Presentation type matching algorithm" may be developed in extending directly of an implementation's underlying type system, as towards a concept of implementation-specific optimization in implementations of CLIM
    • Prospectively, as may be correlated to the previous observation, a CLOS method specializer type may be developed -- albeit, in an implementation-specific manner -- for purpose of specializing CLOS methods onto ordinary Common Lisp type specifiers. Such a formal definition may be accompanied with a thorough description of  how the matching algorithm would be applied, in the implementation, for any single range of Common Lisp union, intersection, numeric, sequence, or other type specifiers. Towards a practical observation, perhaps it may be be a relatively straightforward endeavor, to develop such an extension onto CMU Common Lisp (CMUCL), or the highly specialized fork of CMUCL, Steel Bank Common Lisp (SBCL) -- that, as in referencing the ctypes architecture defined in CMUCL, furthermore inherited by SBCL. 
  • The conventional `define-presentation-type` macro defined in CLIM 2 allows for definition of a presentation type with a quality of multiple inheritance -- albeit, as would be constrained to the set of presentation types defined in any single application of CLIM2
    • In searching for an analogy to CLOS, perhaps it might be thought as that the inherits-from property might be viewed as it being analogous to the class-direct-superclasses accessor defined in MOP,  In a broad sense, it may be similar. 
    • The CLIM 2 specification does not define any analogous processing for the inherits-from property, in any ways exactly analogous to class-direct-superclasses or the computation of a CLOS class' class precedence list.
    • Considering the CLIM 2 presentation types system as a type system, effectively the CLIM 2 presentation types system provides a sort of presentational/interactive layer onto the entire Common Lisp Object System. As such, it might be understood if the CLIM 2 specification does not delve into so many implementation-specific conventions as might be required for defining any manner of inheritance among non-class data types -- e.g. does a hypothetical '(int 32)' extend of a hypothetical '(int 16)', in a "Subclass has a wider field" sense? or vice versa? or not at all? The semantics of such inheritance would be orthogonal to the functional characteristics of any manner of machine-local memory registers.
    • Moreover, CLIM 2 does not appear to define any manner of an accessor for the property's value, for any single object or class as may represent a presentation type definition -- that is, to suggest that the information of the presentation type inherits-from property is effectively lost to any portableimplementation-generic forms, when define-presentation-type  is evaluated. That, in itself, could be revised with an implementation-specific adaptation of CLIM such as to store a value evaluated of the  inherits-from property and to provide that value for applications. Such divergences from CLIM2  should likewise be documented as such.
  • The CLIM 2 specification defines a presentation type history property for presentation type definitions made with define-presentation-type
    • This might seem to introduce something of an orthogonal, application-layer property to the fundamental presentation types system in CLIM.  
    • In a functional sense, a presentation types history property may be applied within an application, as in regards to input recording for values input via a presentation type's accept method(s). 
      • Although perhaps that may seem convenient for development of a CLIM application in any single-application Lisp process, but perhaps this property may be reconsidered as towards a small number of contexts:
        • Multiuser computing environments -- if a CLIM application may be applied in a multi-user Common Lisp process, such that the Common Lisp process may serve multiple users simultaneously -- may therefore contain, at any one time, user data from multiple users
        • Multiple applications in one process -- as for any single Common Lisp process providing multiple CLIM applications to a single user,
      • In either of those instances, the generic presentation type history -- as a property defined of any single presentation type -- might be discarded by the implementation, in lieu of an application-specific and user-specific input recording functionality.
      • This, of course, may serve to call a concern towards the broader input recording  mechanisms of CLIM, concerning privacy of user data in any potential applications of CLIM in any Lisp process providing a multi-user or multi-application environment 
  • Considering, the parameters-are-types property -- as permitted in applications of define-presentation-type -- perhaps the nature of that property might seem a bit confusing, in some regards -- as to its processing for presentation type definitions made with define-presentation-type.  A small number of questions:
    • What specific parameters does the property make reference to, as in  an evaluation of any single define-presentation-type form?
    • Is there an example available, if not a single case study as for when those same parameters, in any instance, would not be presentation types?
  • Looking ahead to when this article might address qualities of presentation functions and presentation methods, then considering a CLOS-based implementation of each, how would properties of CLOS method dispatching -- inasmuch as in a standard method dispatching, and other method dispatching forms specified in AMOP -- how would may any single manner of method dispatching affect the behaviors of a CLIM presentation method, in applications?
Certainly, the design of CLIM presentation types may permit much more of detailed review, as to further juxtapose CLIM presentation generic functions and presentation methods onto CLOS. 

Perhaps, furthermore, an extensional method dispatching framework may be developed for optimal method dispatching onto presentation methods. 

Presently, the author shall endeavor to review the author's own notes, to this point, in this article of discourse.


  • Draft 1: Initial document
  • Draft 2: Concerning the inherits-from property for define-presentation-type, making some little more of clarification as towards a juxtaposition onto CLOS
  • Draft 3: Adding a note towards an analysis of conventions for method dispatching and, orthogonally, application behaviors in a CLOS/MOP implementation of CLIM presentation methods
  • Draft 4: Once again beginning a thesis with regards to UML, SysML, and CLtL2, and CLIM
  • Draft 5: Adding "A short listing of I/O forms in CLIM"

Appendix: A short listing of I/O forms in CLIM, indexed by feature



Appendix: Facilitating discussions of API design decisions, using UML and SysML

Although perhaps it may not represent the most popular of a topic for contemporary discussion, but considering it as a feature of the body of existing work in domains of computing and documentation, the Object Management Group (OMG) specifications for the Metaobject Framework (MOF) and correspondingly, the Unified Modeling Language (UML) and Systems Modeling Language (SysML) metamodels, in each, may be applied for some purposes in illustrating the compositions and behaviors of system elements, as in a system such as of the CLIM 2 specification itself, and in regards to any single implementation of CLIM 2.

Although it may require a substantial design effort -- perhaps, to no clearly popular results moreover -- a metamodel may be defined specifically for modeling of Common Lisp, the Language, 2nd edition (CLtL2) in UML and/or SysML. In a hypothetical extension of such a hypothetical metamodel, a model library may then be developed for describing CLIM2 itself -- in a manner extending of an original mettamodel for CLtL2 -- and a corresponding model library for describing any single implementation of CLIM2.

Alternate to developing a complete metamodel for CLtL2, an approach may be developed for producing an initial UML Profile for CLtL2, such that may extend of the UML and/or SysML metamodels. This approach -- though, to an estimate,, it may seem perhaps more tedious than the direct metamodel approach -- it may serve to allow for that a model developed in an application of the UML Profile could then be applied in any number of existing modeling tools -- such as for generation and analysis of software source forms -- such that any single modeling tool may provide any manner of support for applications of models applying either or both of the UML and/or SysML metaodels.

Not as though the UML Profile approach could not be in any ways tedious in itself, even so much as a simple list structured data type in Common Lisp may require a substantial diagram as to illustrate its complete syntax and possible syntactic variants, in UML. To that effect, the author wishes to make note to albeit an offhand study of some list-structured syntactic forms defined in ASDF,

As one possible benefit of such a work in systems modeling, it may then be relatively easier to present any of a component-oriented view of the behaviors of a CLIM 2 system, in a manner independent of Common Lisp syntax, in applying the resulting UML model library commensurate with documentation. In even more of a hypothetical "Long shot," proverbially: Such an effort in turn, could serve to facilitate a development of a CORBA application model for CLIM2, such that -- lastly -- could be applied in developing an interface onto any single graphical toolkit, in any of the body of existing work in desktop computer interface design, and moreover that could be applied in mobile computing platforms, without any of a specifically platform-centric API.

Of course -- continuing with the ad hoc metaphor -- that would be a long ways to go, to develop a SysML view of CLIM2. Clearly, the popular market may seem to favor much more of any number of immediately stylish applications. Common Lisp not being particularly stylish or immediate, it simply may not "Fit" with "The Modern Market."

CLX on Microsoft Windows - Xming and Cygwin - Notes

As at least a novelty in in development of graphical user interface (GUI) applications, it's possible to develop applications of CLX on Microsoft Windows platforms, using one of the X Window server implementations available on the same platform -- such as Xming or one of the Cygwin  xorg-server implementations.

When Xming installed and initialized, the appropriate display address for the CLX OPEN-DISPLAY function can be determined from the Xming log file. The log file is available via the context menu provided by the Xming icon in the Microsoft Windows system tray

Example: Xming.0.log

Welcome to the Xming X Server
Vendor: Colin Harrison
Release: 6.9.0.31
FreeType2: 2.3.4
Contact: http://sourceforge.net/forum/?group_id=156984

C:\Program Files (x86)\Xming\Xming.exe :0 -clipboard 
 -multiwindow

XdmcpRegisterConnection: newAddress 192.168.56.1
winCheckDisplayNumber - Xming is already running on display 0

Fatal server error:
InitOutput - Duplicate invocation on display number: 0.  Exiting.

winDeinitMultiWindowWM - Noting shutdown in progress

Although, in this example,  some of the content of the log file might seem somewhat ambiguous, as to whether there is or is not an X server initialized on the host, but in observing the IPv4 address that is indicated as the newAddress value -- in this example, 192.168.56.1, an IP address on a local area network -- that address may be applied as the display address to the CLX OPEN-DISPLAY function. Alternately, an address may be provided when Xming is initialized, with the Xming '-from' argument -- for example, as the target value in a Microsoft Windows shortcut object, with some additional command line options provided:
Example: Xming launch command

"C:\Program Files (x86)\Xming\Xming.exe" :0 -clipboard -multiwindow -from 127.0.0.1 -logverbose 1

Subsequently, the address 127.0.0.1 may be provided to CLX.

With Xming initialized to the loopback address, 127.0.0.1, of course that would allow XLib requests from XLib client peers that may bind to the loopback address on the same operating system. This configuration does not require XAUTHORITY configuration. It may be suitable for application in CLX development, in non-networked applications.

SSH may be applied, furthermore, for transport layer security in networked applications of XMing in -- consulting XMing documentation (cached by Google).

Example: CLX "Hello World"

(let* ((clx-sys (asdf:find-system '#:clx))
       (clx-p (asdf:component-pathname clx-sys)))
  (setf (logical-pathname-translations "clx")
        (list (list "**;*.*.*" 
                    (merge-pathnames
                     (make-pathname :directory
                                    '(:relative :wild-inferiors)
                                    :name :wild
                                    ::type :wild
                                    :version :newest)
                     clx-p
                     ))))
  (asdf:operate 'asdf:load-op clx-sys)
  (load "clx:demo;hello")
  (xlib::hello-world "127.0.0.1"))

When working with Cygwin, an X server may be installed with the Cygwin 'xorg-server' package. Documentation is available in the Cygwin 'xorg-docs' package.The X server installed from the 'xorg-server' package may then be initialized with the shell command, 'X'. For information about the implementation of the X server in Cygwin, the reader may also wish to refer to the Cygwin/X Contributor’s Guide.


Saturday, June 27, 2015

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

Friday, June 26, 2015

Walk-Through: Compiling the FreeBSD Base System, Using Source Code Retrieved via Git (Draft 2)

Introduction - Towards a Trusted Computing Platform Derived of FreeBSD

Beginning with the FreeBSD base system, it may be possible to develop a complete platform for trusted computing, with a complete, documented chain of responsibility from source code to application. Such a trusted computing platform -- as initially may extend of the FreeBSD base system  -- may be furthermore extended of the work of the BSSSD project, and the work of any discrete number of additional software development projects, such that the collected software may be applied as to provide fundamental services and userspace applications for FreeBSD as a trusted computing platform. Such a platform may be applied as onto any discrete number of machine architectures for which there is a port of the FreeBSD base system and a corresponding port of each of the collected set of additional software applications.

In a low-level functional regards, such a trusted computing platform may be developed in application of any discrete number of existing features as presently developed in the FreeBSD kernel and broader base system, as well as of any discrete, additional number of userspace applications.  In its development, furthermore, a FreeBSD trusted computing platform may serve as keynote for development of additional kernel  features and new userspace applications.

The author will presently admit the author's own bias, as with regards to a small number of furthter thesis concepts, viz a viz  the author's own "To Do" and/or "Wish List" in many regards of computing:

  • Development of networked userspace applications using CORBA for communications infrastructure, towards integrating the FreeBSD netgraph architecture and I2C daemon for communications among CORBA object request broker (ORB) processes such as may be implemented on a per-interface bases and jailed for purpose of system security, then in an an applciation of the FreeBSD process jail model.
  • Applications of transport layer security (TLS) and authentication frameworks such as SSL and Kerberos, in a CORBA usersrpace infrastructure
  • Scaling of enterprise service models for application of services in small office and home office (SOHO) commercial environments
  • Licensed radio frequency communications on amateur radio bands
  • Computing not indoors
  • Human computer interface (HCI) design in a classical mode, focusing on the Common Lisp Interface Manager (CLIM) and the hardware interfaces available for applications in contemporary environments for desktop and mobile computing 
  • Knowledge development, knowledge modeling, and authenticated knowledge sharing, within frameworks of the original Knowledge Interchange Format (KIF), Common Logic, the Resource Description Framework (RDF), the Web Ontology Language (OWL), and corresponding service models such as SPARQL 
  • Native-coded Common Lisp implementations, including Steel Bank Common Lisp (SBCL) and the original CMU Common Lisp (CMUCL)
  • Common Lisp implementations making a substantial application, each, of C toolkits, focusing on Clozure Common Lisp (CCL), Embeddable Common Lisp (ECL), and Man Kai Common Lisp (MKCL)
  • FPGA programming and studies of the architecture of the original MIT CADR Lisp Machine for possible extension with contemporary bus/interface models, as well as factory-programmed microcontroller architectures, and repgorammable microcontroller archiectures
  • Potential applications of SCADA communications infrastructure models for trusted communications among ground stations and nanosatellites in Low Earth Orbit (LEO) and Lagrangian orbits
  • The Metaobject Framework (MOF) for its applications in the combined Object Management Architecture (OMA) and Model Driven Architecture (MDA) each as a conceptual frameworks for best practice with model-driven tools, developed and published of the Object Management Group (OMG). 
  • Application of the MOF to IDL (MOF2I) transformation, for integration of MOF metamodels, corresponding models, and application runtime data within CORBA architectures
  •  The Metaobject Framework (MOF) as extended with an abstract graphical syntax corresponding to entities defined in the Unified Modeling Language (UML) furthermore extensible with UML profiles inlcuding MARTE, SPEM, and UML4SysML
  • The Metaobject Framework (MOF) as extended with a metamodels for each of RDF, OWL, Common Logic, and ISO Topic Maps, in the ODM specification
  • Archaeologcial studies as may be conducted towards developing conceptual genealogies illustrating progressive developments among correlated, discrete species of structures and systems

In the author's own opinion, considering the previous outline of thesis concepts, FreeBSD may be made to a a most apparent application, as in regards to CORBA services and HCI designs. The singular nature of the FreeBSD base system, moreover, as a fundamental quality of a trusted computing platform, it may serve to greatly aid in the development of any of those or any similar thesis concepts, in any academic and technical productions.


Before Boot 0: Building the Kernel and Base System


The following article is presented as a small effort by the editor, for publishing a small number of assorted notes, as with regards to building a FreeBSD base system and updating the existing FreeBSD base system installed on a FreeBSD host. The following example is developed with FreeBSD 10, beginning with a host on which the EFI-enabled baseline FreeBSD version 10.1-RELEASE was installed from DVD media.

For brevity, and in candor, this article is written with an assumption as that not many people besides the author may be reading this article. Therefore, this article leaves out any manner of further or more detailed introduction or overview text, assuming:
  • That the reader is familiar with the TTY shell environment of FreeBSD version 10.1-RELEASE
  • That the reader is familiar with the Git software change and configuration management (SCCM) tool, at least inasmuch as a familiarity with regards to essential clone and branch operations in Git, secondly familiar with Git revision specifiers
  • That the reader has a user account at GitHub
  • That the reader has generated a suitable private key and registered its corresponding public key in the user's account configuration at GitHub
  • That the reader may be familiar with the screen shell command and a number of more common shell commands such as su and chown
  • That there is a host named builder, configured with a primary non-root user 'me' on the builder host -- such that user 'me' has UID 1000 
  • That the user having UID 1000 will be retrieving the latest source code updated for FreeBSD 10, for compilation on the builder host
  • That the shell command eval $(ssh-agent) was performed at time of user login, to an effect that an ssh-agent process is initialized, is running in the background of the controlling terminal, and that the SSH agent will have published the bindings for a corresponding set of environment variables, for evaluation during the login process. Any subsequent child process forks may then read those environment variables, contingent to communicating with the SSH agent process.
The following shell session begins with the user 'me'  logged in on a terminal on a host in which FreeBSD 10.1-RELEASE is installed. Previous to the main work of the script, the user calls ssh-add to ensure that the user's default private key on the builder host will be read and stored in memory by the SSH agent process. This procedural step is performed at the user's discretion, essentially as a matter of functional convenience, previous to downloading the base system's source code via GitHub.

Subsequently, a screen session is initialized, such that the shell process forked by the screen session will inherit the shell environment of the earlier shell process -- thus, including any environment variables as may be necessary for further forked processes to communicate with the background  SSH agent process.

Lastly, the host's existing /usr/src source tree is moved to a temporary location on the filesystem, such that the original source tree may then be stored in a tape archive and optionally removed from the filesystem. A new /usr/src/ directory is then created, with ownership by the user 'me', having UID 1000. The user  'me' then exits the superuser process.

Subsequently, the 'me' user downloads the base system source code repository via GitHub. The FreeBSD releng/10.1 branch is retrieved, firstly, such that that branch, as locked at time of retrieval, will then be available in the local base system's source code repository on the builder host. This step may be performed as in the interest of a possibility that that the original, upstream 10.1-RELEASE source tree might be needed for any manner of later reference, in development tasks.

The /usr/src directory, in its end state, will contain the source code of the FreeBSD stable/10 branch.

Example: Shell session for checkout of FreeBSD base system via the FreeBSD Project's freebsd repository at GitHub

[me@builder ~/]$ uname -a
FreeBSD builder 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
[me@builder ~/]$ cd /usr
[me@builder /usr/]$ ssh-add
... interaction ...
[me@builder /usr/]$ screen -S base
... screen session ...
[me@builder /usr/]$ su
[root@builder /usr/]# mv src src_FreeBSD-$(uname -r)_ISO_src
[root@builder /usr/]# mkdir src
[root@builder /usr/]# chown 1000 src
[root@builder /usr/]# exit
[me@builder /usr/]$ cd src && git init
... output from git ...
[me@builder /usr/src/]$ git remote add origin git@github.com:freebsd/freebsd.git
[me@builder /usr/src/]$ git pull origin releng/10.1 # 10.1-RELEASE (frozen)
... output from git ...
[me@builder /usr/src/]$ git pull origin stable/10 # development for FreeBSD 10-STABLE
... output from git ...
[me@builder /usr/src/]$ git reset hard && git clean -fd # cleanup after merge to implicit local master branch
... output from git ...
[me@builder /usr/src/]$ git checkout stable/10
Branch stable/10 set up to track remote branch stable/10 from origin.
Switched to a new branch 'stable/10'
[me@builder /usr/src/]$ git branch
  master
* stable/10
[me@builder /usr/src/]$ git branch delete master
At that point, the directory /usr/src contains the latest updated source code from the upstream source repository at GitHub, with the source tree of the upstream branch stable/10 then checked out into /usr/src/.

As an orthogonal note, Git will have created an additional master branch during the initial pull process. In that script, as illustrated, the Git reset and clean commands were applied as to clean up the local source tree as to prevent a collision between the implicit local master branch -- as was initialized from the releng/10.1  upstream branch -- a collision that would otherwise occur when  the upstream stable/10 branch is subsequently fetched and checked out into the local source tree. The final shell command in the script will have deleted that implicit master branch -- otherwise, it might cause any number of further revision conflicts, during the process of branch checkout. 

In order to prevent the initial collision, moreover, the git fetch command could be applied as instead of the second git pull command in the script. The git branch delete   master command could then be performed before the final git checkout, thus ensuring that the local source tree would then contain an exact representation of the upstream source tree, with no initial collisions in source files.

The builder host may then be prepared for compiling the base system.


Notes: Optimizing for Build

To the author's best assumption, the LLVM C compiler toolchain may be installed  as a part of the FreeBSD base system.

Previous to this task, the Poudriere build automation tool had been installed on the builder host. Poudriere was subsequently applied for building a small number of FreeBSD ports, using the Hardpan autoport shell scripts,  It may be assumed that the C compiler toolchain, at the time of this task, was correctly configured for the host.

In order to ensure that the LLVM C compiler toolchain will produce object files such that may be optimized for the microprocessor installed o the builder host and for similar microprocessors in hosts on the local area network (LAN), the following configuration properties had been specified in /etc/make.conf.
CPUTYPE?=core2
CFLAGS+=        -msse3
CXXFLAGS+=      -msse3

COPTFLAGS?= -O -pipe -j4
FORCE_MAKE_JOBS=yes
MAKE_JOBS_NUMBER=4

The previous configuration should furthermore serve to ensure that the C compiler will be applied in parallel jobs, when using the LLVM C compiler toolchain as in a manner independent of other build automation tools. Consulting the documentation for build automation tools such as Poudriere, the respective build automation tool may offer a number of additional options for controlling a build process.

Notes: The Build Process - Kernel Build

... TBD ...

... sidebar; kernel configuration profiles ...

Notes: The Build Process - Base System Build

... TBD ...

Notes: Installing via NFS

Courtesy of advice presented in the FreeBSD community support channel on the FreeNode IRC chat network, the author has learned of a recommendation. in effect, as that files compiled of 'make buildworld' and any static, host-level files of the FreeBSD base system may be installed for system update over a local area network, using a networked filesystem (NFS) share mounting /usr/src. Such a configuration may serve to allow for 'make installworld' to be called on each respective host where the NFS share is  mounted. This, in turn, may serve to allow for any manner of host-local change management to be performed for configuration files on the respective installation host, during the make installworld process.

It may be furthermore advisable that the NFS share would not be published to the network, until after the initial build process will have successfully completed.



Bibliography

… Meta-IDE …

Ed. Note: The following article comprises a set of notes with regards to a concept of development of a meta-IDE platform for developing software with a FreeBSD server and desktop platforms, in parallel to Linux desktop, Microsoft Windows desktop, and Android mobile platforms, hence a concept of a meta-IDE

This article was developed in an interest of brevity, as a short sketch illustrating a small number of correlated concepts.  Not much of a conceptual glue is provided, in this draft of the article.

What's in an IDE?



… ECMA TR/69 … CMM …

… file editing, SCCM, toolchain automation (test build, main build), distribution signing and automation … Quality Assurance … user support … issue tracking … tasks and processes …


Desktop as Development Environment




Towards a Cross-Platform Userspace



An entrepneurial small office / home office (SOHO) local area network (LAN) may include [computing machines]

Desktop PC (laptop)

Mobile Phone (smartphone)

Tablet or Notebook PC

Single Board Computer Appliance (BBB, RPi, CubieBoard, …)

Manufactuted IoT Appliance

LAN Gateway Appliance

Network Access Point

Internet Services Host

… [applications] …

… [web applications] … [local backups qnd archiving] …

(This outline assumes that the network space between the Network Access Point and the Internet Services Host is not managed by the SOHO Network Owner.)

(An Internet Services Host may or may not be managed by the SOHO Network Owner.)

Towards Specialized Network Service Profiles

… multi-user SOHO LAN … authentication … name services … LDAP … DNS … Samba … Network trust … DNSSEC and DNSCurve …

… untrusted networks … non-repudiation … ad hoc VPN services … owner-managed VPN services …

… device-level/interface-level authentication … X.509 certificates … key pairs, CAs, keychains, and CRLs … TPMs … {TCG} … BSSSD …

… message trust … nonrepudiation … key pairs… message signing … message signature verification …

… user trust … Kerberos … one-time passwords … multi-factor authentication …

… process/resource trust … FreeBSD MAC modules and ACL definitions … xref to SE Linux … FreeBSD process/filesystem jails … ezjail (ZFS, UFS images) … io{fum} (ZFS) …

… knowledge management, proprietary knowledge, creator's rights, intellectual property, legal frameworks, semantic abstraction, sciences and mathematics, academia, knowledge sharing … KIF … Common Logic … RDF … OWL … Topic Maps … MOF, UML, and ODM …

… Enterprise information services for small enterprise … MOF, UML, MOF2I, and CORBA …

… content creation … maker's rights … multimedia formats … content curation … originality … social events … m3rch, memorabelia, rights management,  and merchandising …



Future Directions

• CORBA to web services gateways (Evernote, Diigo, RefMe, …)

• CORBA GIOP and I²C

• Modbus for Nanosats

• Appliance2Cloud information process (incl. MODS, PREMIS, DCMI, X.509, … ODM … CORBA …)

• FreeBSD ror M2M Computing (BBB, Yantrr capes, FreeBSD base system, Poudriere and autoport, … )

• HCI 2.0 (CLIM, EFL, WebKit, … CORBA …)

Thursday, June 25, 2015

Toolchains and the Trees -- Personal Anecdotes and a Thesis of Applying Common Lisp with CMake

Personally, one of the greatest sources of confusion I've found about software development, it's a matter of the toolchains. In some of candor, it has been a long-standing issue to me as a computer user, extending at least to so far ago a time as when I was in high school, reading catalogues about the newest compilers then from Borland and others -- circa mid 1990's. By that time, I had learned some very little about Linux -- it seemed to have something of an "Underground" style, to my best recollection of my own youthful views at the time. Certainly, Linux and the GNU Tollchain GCC have much matured, over the years. Personally, I'm still trying to figure out toolchains, though -- not presently worried about marketing.

My own first endeavors in computer software programming began as early as the Tandy Color Computer 3, a gift from an uncle to my economically lower-middle class family and  myself. I was a student of a decent school district, then, but BASIC wasn't the greatest thing to program with. I struggled with BASIC, on through to those years in high school, aside so many far more personal concerns that I was met with, in my life's time then, and then my own small endeavors in performing in the theatrical arts, for a short time albeit, and keeping up with school and extracurricular activities, including Academic Decathlon and -- before theatre took all my time after school -- hurdling, in track and field. I also stutter stepped, then. It was pre-online-social-networking. I already had a lot on my shoulders already, as a young person. That's of life as I knew it then.

Ironically, in my life as an adult, I'm not pressed with nearly so many of personal difficulties. Some of the issues I was pressed to deal with, during those years in high school, it was literally more than I could handle. I would not wish to make a mere sidebar about teen pregnancy, it's an issue I am too familiar with already. Personally, I'm familiar with concepts of diasporas and institutions, and -- by now -- I've studied some of a formal anthropology. To my mature thinking, I try to limit my thoughts of diaspora to any works akin to Aesop's fables. There's more to life, surely, and there's always, always a broader sky.

As being now of the age and perhaps the maturity of an adult -- my being furthermore familiar with some concepts of some proprietary systems, moreover -- I go out of my way to try to limit my comments about information theory to only any sort of abstract, rudimentary kinds of concepts as I can think of.  As such, I've become much more a fan of mathematics, in my adult life -- my many regrets aside, personally, if I had not understood so much of mathematics during high school, as might be due to some, well, some cognitive dissonance as I've learned to live with, in my life. There's a sense of resilience in things, surely, and mountains too, even in the darkest of times.


So, nearly in the fourth decade of my life, by now, I'm still trying to understand toolchains. It's not to be just pointlessly stubborn, I'm simply not a fan of brand names aside of actual tooling and other concrete concepts of software and things. Personally, I consider that if there was a Linux kernel for the 8086, in the 1990's, I could've been learning a great deal more about computing, but that's a thought in hindisght. I've yet to look into the question of whether I could put FreeBSD on my newer Tandy 1000RL. I would imagine that I might have an easier time porting FreeBSD for that old machine's architecture -- it would be quite a novel thing, certainly emphasizing of some rudimentary concepts in microprocessor design, in this era of mass production of systems applying semiconducdtors. What could be next, in the great curve? Perhaps more of thermodynamics, if not some of a quantum and optical computing. Presently, I'm more interested about toolchains, and human computer interface (HCI) design. There might be, perhaps, some cognitive dissonance that I  might find today between, those two concepts -- a sort of, perhaps, an immaturish tendency as has  lingered with me, to my adult years, together with a persistent knack for "playing dumb" about whatI truly do not know. HCI design being. no doubt, one of the great pinnacles of software development, why do I find it so truly difficult? Is it all technical, my sense of concern at that?

There are toolchains, and there are architectures. There's even a platform-agnostic, abstract visual syntax developed among all things under the sun, namely as a part of UML MOF, and the Object Management Group's broader concepts of Object Management Architecture (OMA) and Model Driven Architecture (MDA) such that one might denote in a logical sense, OMA * MDA -- albeit, in no immediate study of trademarks and terms, but simply noting a sort of a logical conjunction of those two respective concepts. One concept that I am not well to be cheerful about: As if anyone could voluntarily present a price tag for a thousand dollar compiler to a mechanic's son, and there's something in many ways "Free" right beside it. I understand, that was not an intentional coincidence, though it was to much of an untimely observation, in my own youthful experiences. Consequently, I pursued a lot of time-wasting in the arts, but not ever completely forgetting the sciences, until a few years going nowhere, the a few years enlisted as an Engineer. That time in my life, I talk far around it, not to inspire any radical sentiments about institutions and singularly, the US military. To my thinking, it was a belated enlistment. I'd have done well to look closer to the earth, sooner, but I was  much inspired by the work of NASA, and so much of a positive, English language science fiction of the Cold War. Sure, it was more than science fiction, all the events of those years in the political histotries of the world. If there was ever a place not affected by the Cold War, I'd not go out of my way to illustrate.

Presently, this is not a thesis about proprietary philosophy, nationalism, or intelligence services. I can write more clearly and more succinctly about those concepts, perhaps, if those are concepts I may wish to consider as though I am in any ways familiar with, as a grown up son of the Cold War, so to speak. Oh certainly, I've heard some liberal jokes of it -- I was a cadet in the Civil Air Patrol not to be mocked by staff of an aircraft maintenance facility, though I well remember receiving a remark as such -- somewhere at where there was a US Air Force base in Sacramento, before it was closed, sometime before the Cold War had made any of a sense to me. What was it, then, except a gross theater of nuclear deterrence? and I had thought that was all wrapped up by now, but there are still silos being trenched out in the world. So, apparently that much is not "All over." I doubt it'll ever be resolved with any of a WWI style of conflict, though I'm pretty well familiar with some events of Ukraine, in these years. It would seem as if anyone had thought as if that crisis would ever get better with more artillery fire? and then the missives launched out across social networking, needless to say of what's actually gone on on the ground in East Ukraine, the suffering, the horror, all the things that people would surely not want to read about, or see in any graphic detail. Who's to help it, and is the news only pitched to smear the reputation of all of Russia? What kind of a coordination would it require, if that was actually intentional, in any regards? I refer to it, now, as "The Vortex," it's beyond my ability to estimate how it ends, though I consider I've learned some of how it began.

To my best estimate, the political state of the world is in all of an odd place, these days, and the global intelligence community no less so. Personally, I'm no more a fan of politics than ever.  I'm not an intel spook, myself, though I consider I understand some of the process of intelligence. It's been to all of an unhappy knowledge, as soon as I so much look into "A hunch," an unhappy knowledge but a knowledge of actual events in a part of the world scarcely ever reported of in any news I see on the TV. Like the cognitive dissonance I lived with as a child, I now must live with more of morally awful knowledge as an adult. I try to keep my own backpack light, at that -- there's enough of personal weight already riding in my own backpack.

Would it be easy to explain how communications pertains?

And here I'd begun this article, thinking as though CMake was any of a ponderous thing to understand. Perhaps there's something of a sense of perspective, in something of a sense of gravity.

Personally, I've already reached the decade-era "High water mark" for receiving news of atrocious crises. Perhaps I'll have not ever read the last of such, in all the world -- nothing to say for how crisis shapes discourse, and not in always well so, though it's said to be "Only words?"

Certainly, there's nothing of a sense of nuance in an application of a software tool, not any of a great sense of metaphysics in how a machine coded object runs on a micrprocessor, an no great vaguery to the calculus of finite differentials, not a whole lot to personally say of simple algebra, and though geometry would seem ever like a novel topic, it's devolves to mathematics and a discrete logic, if not moreover a sense of scientific philosophy -- referencing, in the last point, Haskell Curry's thesis about logic. Nothing to a metaphysics of discrete microprocessors, or the science fiction of the cyperbunk genres of the 1980's, no great bonfires to stoke about the old AI Winter -- simply, there is a computer screen right in front of me, it's displaying a web browser developed by Google, within a desktop environment developed by Microsoft Windows, on a personal computer developed by the Hewlett-Packard company, and there's a taskbar on my desktop.

Not pictured, in this literal landscape: The Common Lisp Interface Manager (CLIM), the Common Object Request Broker (CORBA), or the FreeBSD Netgraph architecture, and internet sockets. There could be a number of thesis concepts in that, somewhere, perhaps some thesis concepts also addressing, so to speak, a sense about I2C in "bare metal" microcontroller architectures.

Presently, I would like to begin a thesis to illustrate how CMake can be applied -- ideally -- for compiling the Enlightenent EFL toolkit along with a WebKit adapter for the same, as available in the EFL WebKit distribution, but compiling the lot for Microsoft Windows, Linux, and FreeBSD desktop platforms. I'm not immediately certain if it's all "Instantly" possible, though.

So, to try to develop a place to anchor my thinking to, personally, I've considered that it would be useful to denote a concept of toolchains -- but not to limit the concept only to the GNU Compiler Collection (GCC), not even to limit the discussion only to LLVM.

CMake, in itself, would not be exclusive to LLVM -- observing that, and writing the observation down, I might understand if it might not jar against applications of LLVM tools in FreeBSD.

Aside to that, the developers of Clozure Common Lisp (CCL) have developed a fork of FFIGEN. Perhaps CCL's FFIGEN it could be applied as for an integrated builld platform with CMake and Common Lisp -- in Common Lisp development, focusing on CFFI or anything similarly supporting of an application binary interface (ABI) for accessing C libraries in Common Lisp.

So there's the thesis concept I had not set out to write, originally: CMake can be used for build automation in a toolchain including a Common Lisp implementation, or CMake can be applied for automation by a Common Lisp implementation.  In either regards, certainly Common Lisp and C can be integrated into a broader toolchain, through any number of discrete methodologies.Personally, I think I'd wish to favor the approach, "CMake calls the CLtL implementation," at least initially. For a project using C and Common Lisp, in which the C code, once compiled, would be linked from within the Common Lisp implementation, certainly the C code would need to be compiled first, then Common Lisp could be run to load/link and test an application's integration with the same C code. The whole build tool -- for instance, CMake -- it could be run external to the Common Lisp process, of course. Barring any resurgence of the original Lisp operating systems, moreover with regards to contemporary microcontroller architectures, certainly a Lisp process would be run by an operating system, usually not running as the operating system, in most operating systems.

So, if CMake can be applied as to build the EFL WebKit integration from source code, and could later apply Common Lisp to objects compiled from the same, but to a tantamount question then: Would it not build the Common Lisp implementation from source code, too? Whether or not, how would CMake select which Common Lisp implementation to run, in any manner of functional testing?

At that, I think I've found the first challenging thought of the thing -- and, again, it's a trivial concept of toolchains.

Local Area Networks Named after Minerals - an Introduction

Insofar as towards applications of information science in development and application of computing systems, I've been developing a small framework for a small local area network (LAN), using FreeBSD. This week, I've been able to install FreeBSD on my 17" Hewlett-Packard (HP) Pavilion personal computer (PC) and to boot the operating system successfully. This would entail an application of the HP Pavilion's implementation of the Unified Extensible Firmware Interface (UEFI), using the Pavilion laptop's hard disk drive, the latter having a GUID Partition Table (GPT)  format.

I'd installed FreeBSD from the EFI-enabled DVD release for FreeBSD 10.1. Though personally, I was concerned about whether or not the installation might be compatible with the laptop's EFI and GPT framework, but -- in regareds the FreeBSD installer's menu options -- the FreeBSD installation itself required no further modifications in order to bootstrap from the hard disk drive. I'd already configured the laptop's BIOS implementation for legacy boot. Although the laptop cannot presently boot to FreeBSD, unattended, but considering the relative simplicity of the 'ESC... F9' key sequence required for boot device selection at the boostrapping state, in the laptop, and the subsequent selection of the appropriate EFI hard disk partition, it's no great difficulty to boot FreeBSD on that laptop, ultimately using FreeBSD's own boot loader framework -- from the 'boot0' initialization to the final 'loader' application. Personally, I would like to speculate that it may be possible to furthermore configure the laptop's hard disk drive such that the FreeBSD boot loader may then effectively replace the boot-time EFI  menu option, labeled "OS boot manager". So far as the laptop now has a working FreeBSD operating system on it, I believe it's arrived at at steady usable state, as a PC.

Of course, it may not be enough to simply make an artifact of the installation. Proceeding from the initial FreeBSD operating system "First boot" stage, I've installed FreeBSD's Poudriere build tool. Beginning from a simple shell script that I'd begun developing, after installing FreeBSD on my LAN's gateway appliance -- perhaps a relatively less remarkable feat, on that PC, it entailing an ordinary BIOS and MBR  configuration -- I've built a small number of software packages, optimized for 'core2' microprocessors, and primarily for terminal-level applications.

Proceeding from that point, I've still a small number of "To Do" type tasks to complete with my newest FreeBSD installation, viz a viz

  • The "Update base system and kernel over LAN" option
    • To install and configure a network filesystem (NFS) server on the LAN gateway appliance, the latter having served as an initial build host for an updated FreeBSD base system, likewise then optimized for core2 microprocessors
    • To configure a NFS client on the newest FreeBSD installation
    • To have configured the server and client in such a way as that it may support a one-time installation of the results produced by 'make buildworld', in updating the newest FreeBSD installation via NFS
    • To document this series of steps, in such a way as that I  may be easily able to reproduce the process, on my newest laptop, an HP Pavilion x360 notebook.
  • The "Build LAN appliance profiles" option -- that entailing much of a configuration for cross-compiling on an amd64 host, compiling for an ARM host. It may also entail an application of a netboot architecture, for bootstrapping of ARM appliances without further tedium in regards to installation. Lastly, on the amd64 host, it may entail a further application of Poudriere, Once the installation would be complete, for each respective ARM appliance, then it might entail simply some rudimentary terminal-level configuration. The bootstrapping and debug processes may be the most challenging to address, in this model.
  • The "Install desktop environment on my FreeBSD PC" option, in applying FreeBSD on an amd64 PC for developing a simple desktop computing environment.
  • Additional "developer novelties" such as:
    • Further study of C programming
    • Further study of Kerberos and Secure Sockets Layer (SSL) systems
    • Further study of CORBA architectures, as something of a matter of application-layer communications infrastructure on an IPv4 network, as may be furthemore complicated of Kerberos and SSL
    • Further study of the architecture of the FreeBSD kernel, my hoping to focus my own attentions as towards applications of the Netraph architecture in FreeBSD
The task that I've denoted, with the phrase, "Install desktop environment", to my understanding it would seem to be the least deterministic task in the list. Not only is there a veritably ginormous variety of alternatives available for developing a desktop environment in FreeBSD, furthermore any single selection of FreeBSD desktop tools may be optimized of a local port build -- and then there is question, by far orthogonal, as to how much of the resulting architecture may ever be applied onto a Microsoft Windows desktop, and by what manners of a means to such a state? Broadly, it may serve to call on a concept of software architectures, if not an opportunity to introduce some concepts about the operating system that I keep denoting, in this article.


Sidebar: Proprietary Convention, Unproprietary Science

The author assumes that perhaps the reader may have be in any ways more familiar with the present topic, perhaps in regards moreover. with more "Time in shop" than the author, as to applications of the FreeBSD operating system, in the kernel, base system, and userspace applications of any single distribution of FreeBSD. Perhaps the reader may even be familiar with any numner of typically proprietary applications of FreeBSD. To the author's own point of view, a software architecture in itself may not be an expressly proprietary concept, however some operating systems have been commercially branded, across any number of discrete eons in Internet history. Inasmuch, the author would by no means ask any reader to divulge any manner of proprietary concepts as towards designs or applications of computer operating systems, Aside so many of the fables of Aesop, historically -- a proprietary manner of success perhaps seeming like the highest grape on the arch, so to speak -- however, the author wishes to believe that in computing, all works may be derived of an extension of sciences and mathematics. Not as though to make a mythical ordeal of a concept: That whatever extensions there may be, in any manner of abstraction, extensions produced of original works in the mathematics and the sciences of computing -- that whatever there may be of proprietary notions,  moreover, in concepts of designs and implementation of computing machines -- that however far any institution  may ever brand in application of semiconductors, in works made under the sun, and in projects directed more towards a location of the earth's core -- as in consideration of the terrestrial mining projects below the sun-swept surfaces of the earth, and projects addressed to the surfaces of the seas -- that beyond all concepts of brands and branding, and beyond all modes of storytelling and the storytellers, semantically and functionally it's all an extension of the maths and sciences. Thus, so many proprietary concepts may resume a neat, tidy arrangement as being products of projects produced in scientific developments of existing work.

As anyone whom owns a personal computer being a software designer -- in any discernible manner of abstraction, a computer owner at least designing software applications as may be developed in worflows produced of existing software products, a sort of "Value added" endeavor, if not moreover writing lines of software code as to cause a computer, ideally, to perform "New work", in any dicrete sense of "The new"  -- certainly, anyone whom owns a personal computer may be likewise considered as a stakeholder in the nature of computing, itself. Viewing a matter of semiconductor manufacture, then, as of an ever broadening and ever more specialized field of practice -- not neglecting the untold potential of new developments for semiconductor manufacture, and the contentious questions perhaps not yet unaddressed of material technology, such  as of whether or not it may be possible to produce a microchip in a zero-gravity near vacuum of outer space -- it is not as if to relegate a work of computing to the doldrums of material micromanagement. As stakeholders, perhaps we may think more broadly about the existing works under the sun.

Such a philosophical introduction aside, if only momentarily, the author hopes that he may presently resume a development of a single technical thesis topic. Though perhaps it may seem to verge towards the proprietary, characteristically, but if it is not without something of a broader sense of view, the author hopes in all sincerity that the author's own thesis topics may not be too coldly received by the court of public opinion, in any media or in any society as this online media may be received by. Essentially, there is a broader mathematics of computing, such that may be traced to the very origins of logic and communications. As the author being a stakeholder likewise, the author's own "Piece of the pie" may represent only a very small fraction of all of the existing work yet known of humankind, in development of computing machines. As to the subtler nature of a concept of metasemantics, the author would not wish to distract the reader, in developing this present article of discourse.

The history of development of computer operating systems, broadly -- if such a very broad archaeology may be denoted, in however of an abstract view, as a single concept -- such a single concept, in itself, may represent a very broad topic however, not even singularly addressed of all operating systems as ever distributed from singular servers. Individual operating system distributions, moreover -- inasmuch as of applications of operating systems -- from points of implementations, any single concept of an operating systems may be observed moreover as for how an operating system is applied, in any manner of a proprietary workflow, in any manner of a proprietary production. Not as if to entertain any theory of social mechanism, an analysis of an application of an operating system may be approached as though to produce an analysis about added value, as in regards to applications of computer operating systems -- if there may be any single application of computer operating systems such that would not be in itself a controlled property, an intellectual property of wherever it is developed of, and wherever applied.

The author cannot by any means ignore that there are proprietary models for development and applications of computer operating systems -- however much a matter of best practice, however much a matter of proprietary convenience in communications, however further a matter of resources of intellectual property managed under known auspices, however not publicly known. In any regards, perhaps a concept of a proprietary design may serve to lend a sense of focus towards a work of production in the broader computing -- if not only narrowing towards a concept of a specialized contrivance. So, not to narrow a thesis beyond any scientific view of any specialized designs, and neither as if in any ways to radicalize any of the present set of existing works, on the web -- the author must presently take pause from this simple thesis article. It is as though all of a community may set itself afoot as to impede any of a further progress in a conceptual design, to distract, to dissemble, and to nearly disembowel any of a concrete concept, as soon as any of a sense of progress may soever seem as if to have begun, if a thing is ever put forward before it is all complete already. 

There is a complete nature of mathematics, a nature not asking or assuming anything more of the open universe, merely asserting 2 + 2 = 4 in conventional addition. Likewise, there may be a complete nature of technologies applying of mathematics. from the earliest logical system to the latest specialized, logical or numerical calculus ever emerging of contemporary academia. What simple mathematics may there be, furthermore, to the old assertion of "Hacking" as juxtaposed to engineering, in any of a classically benign sense of "hacking" moreover? What, then, of marketing, and the "Sports car effect?" The author shall endeavor to present a thesis of these concepts, too, henceforward.

Species and Formulas of Licensing

In a sense of developing knowledge, in any field in which oneself would be directed to be cognizant of, perhaps it may be as well to observe of when oneself is lacking knowledge in a matter? Though it might not make for a good read, to write, "I don't know," but even in an unknown conceptual area there might always be some further knowledge to proceed back to? The author being not a doyen of the Microsoft Solutions, and neither a Shaman of Linux kernel design, but quite a fan of Tandy's old Deskmate, and the uncluttered environment of FreeBSD. 

Deskmate was an operating system derived effectively after Digital Research's CP/M, more directly derived of IBM-DOS -- however aside the lawsuit after Traf0Ddata made a conspicuous theft of Digital Research's work in CP/M, moreover involving an interaction with IBM. Deskmate itself was featured in some Tandy computers, near a time when Microsoft had developed a window shell on top of an MS-DOS system. Parallel to those consumer-focused products, there's been all the evolution of UNIX. Parallel to the lot, there was Apple's emergence during and previous to the convenient year of 1984. Furthermore in parallel, there's the old legacy of Lisp Machines, however gone in the drift of the AI Winter. In all of the broad sky of operating systems -- and the more of desktop operating systems that the author has not denoted, including BeOS -- perhaps in a candid sense, the old "Microsoft vs Linux" conflicts might seem like some theatrics, previous to that there was an issue of a legal conflict as in the SCO lawsuit. Considering that the SCO lawsuit had effectively introduced a concept of source code licensing, in a legal conflict in the courts -- thereby, a further concept of an intellectual property in computing machines -- and if the very act of reading a line of source code could entail, of itself, a licensing issue, but is there not a science-friendly operating system under the sun?

The unpretentious BSD license, in any species of BSD license, it asks not for any further application, sufficing as a single license about a single product, in every instance of its application. Perhaps it may seem much akin a mathematical concept -- the BSD license, itself, not asking any of a marketer's assistance for its validation,, not either in commerce or software development. In a sense, the validity of the BSD license -- in applications of software -- is founded entirely on the characteristics of the software it licenses.

Towards an Overview of an Architecture of FreeBSD

The present topic -- there's a lot of work under that heading. The author cannot pretend to have encompassed it all, in any one sitting. If the author has newly discovered some resources under such a heading, it might have seemed well to begin to collect the references and to present a list of resources for public consideration. Concerning the metaphor to mathematics, however, perhaps it may be as well to simply apply what there is?

The author hopes to resume a more succinct manner of writing, sometime. The canvas, so to speak, it might seems to need a broad brush, today.

Wednesday, June 17, 2015

Chromebooks - Utility and Adaptations

Chromebooks - Utility and Adaptations 

  • Availability at Amazon.com
  • Ultrathin laptops
    • Small form factor
    • Limited power consumption
    • Lightweight computing
  • ARM platforms available 
  • Stocked with Chromium OS
    • Chromium OS development
    • Web-oriented architecture
      • Google Chrome browser
      • Google Chrome app store
      • Google docs, etc
      • Dissimilar to a conventional desktop environment
    • Chromium OS is locked into platform
    • Alternatives to ChromiumOS?
      • With some modifications to the platform, a complete OS installation can be made
        • ...in chroot (e.g with Crouton)
        • ...in dual boot (e.g with ChrUbuntu)
        • ...or "bare metal" 
          • Bare metal installation with original BIOS
            • 'Developer mode' still enabled 
            • OS can be wiped inadvertently
            • Legacy BIOS must be accessed for each boot
          • Bare metal installation with custom BIOS
            • Flashing the Chromebook BIOS - non-trivial
            • Hardware modifications then required
              • Vendor-specific
              • Proceed at own discretion
            • Allows for further flexibility in applying the Chromebook as a hardware platform
      • Documentation: Installing Bodhi Linux on a Chromebook [Bodhi Linux wiki]
        • Option 1: Install for dual boot [Bodhi Linux Wiki]
        • Option 2: Bare metal install with upstream  BIOS [Bodhi Linux Wiki]
        • Option 3: Bare metal install with custom BIOS
          • Not documented at Bodhi Linux Wiki
          • Hardware modifications previous to flashing BIOS
            • Proceed at own discretion
      • Documentation: Coreboot and Chromebook platforms
      • Documentation: flashrom utility
      • Documentation: Developer information, Chromebook hardware
      • The "Bricked Chromebook" - proceed at own discretion
  • Case Study: Samsung Chromebook (Exynos 5250)
  • Further resources: Custom firmware images for Chromebooks, pre-compiled
  • Further wrench-turning may be required.

Tuesday, June 16, 2015

On Building World - First Pass with FreeBSD 10 amd64/core2

With apology to the reader, though avoiding to develop an outline of a thesis about designs and implementations of operating systems, or either the difficulties before understanding the non-trivial sciences of systems in information processing and communications -- as when the schools are not even teaching from the sciences -- but simply, as a note of some text printed by the FreeBSD 'clang' compiler, this morning, I've noticed some of an error output like the following when building FreeBSD from the releng/10.1 branch., the source code from the FreeBSD repository at GitHub.
/usr/src/secure/lib/libcrypto/amd64/x86_64cpuid.S:17:8: error: register %rdi is only available in 64-bit mode
 movl (%rdi),%eax
       ^~~~
My not being a great aficionado about compiler toolchains, then after that message was produced and the build halted, I discovered the availability of the the stable/10 branch, in the same FreeBSD Project's source code repository. I've now made a local freebsd_10 branch drawing from the same upstream branch, and will proceed to....
make buildworld DESTDIR=/usr/local/myworld
...hoping that perhaps it may build, this time. I'm compiling the FreeBSD source code, with /etc/make.conf containing the following
MACHINE_CPUARCH=amd64
CPUTYPE?=core2
MAKE_SHELL?=sh
CFLAGS+=-msse3
CXXFLAGS+=-msse3
COPTFLAGS?= -O -pipe

Albeit, those were somewhat some arbitrary selections, but it seems to have worked out, so far.

Why would I be enjoining myself to this perhaps seemingly masochistic task, this morning? Initially, I'd thought that it could make a nice result tree for a compiler jail for Poudriere's build automation, such that I might then apply -m null -M /usr/local/myworld for re-using the built objects when applying the poudriere jail command. If the packages could be built against a compiler-optimized core system -- as I'd thought might this morning's make may have produced -- then if that would work out, to apply the compiled world in a process of build automation with Poudriere, then I'd thought, I would consider installing the same /usr/src world onto my host's own root partition, perhaps  then even trying to package it up for installation onto my own amd64 laptop.

Later, I'd thought, I might be able to trust if I've understood how the FreeBSD build process works, well enough that I might then endeavor to build an ARM world -- that, as for applying FreeBSD with BeagleBone Black single-board computers in my own LAN. So far as the LAN design, that much would be trivial, pending the successful installation of a stable, trusted, and uncluttered operating system for the LAN's appliances. I've certainly selected FreeBSD at that -- no more to find interference from NetworkManager about the contents of /etc/resolv.conf -- but, so to speak, the Pokemon ball is just staying welded shut.

Personally, I think that I'm wishing now that the whole build process could be more modularized, in FreeBSD, but not to leverage any kind of an agenda about it. I only wish that I would not have to rebuild the entire FreeBSD local world  if to simply rebuild a component that had failed in the previous build process.

There is one positively simple thing that I've learned, in this morning's effort thus far, namely: That rather than
/bin/fie 2>&1 | tee /some/fum.log
There's a much simpler syntax available with the script shell command:
script /some/fum.log
/bin/fie ...
...such that the script command conveniently receives text printed to both of the standard output and standard error streams, prints the text to the console, then also prints the text to the log file.

So clearly, there are some real reasons for reading the FreeBSD handbook. I believe it's all something to do with knowledge.

Monday, June 8, 2015

Thank you, world wide technical help desk

Not to be too awfully opaque, as a student of an electronics and computing program at a certain institution conventionally denoted as a university, I've been studying some topics of electronics and computing, within and in parallel to, if not furthermore in support to a formal program about the same. In forwarding on my own individual and personal experiences in communications and software applications -- moreover, in focusing on something of a sense of small enterprise, albeit while studying presumably in an audience of corporate enterprise, at the same institution -- personally, I've been trying to focus on "Small data," not reading too much into the "Big data" of any characteristically corporate statistical estimates.

My being of an impression that, in the highly politicized world, I must naturally expect any reader in the general web readership to make a manner of a political character of estimation of my own, simple writing -- that, in and after my own previous experiences with web readership, in online communications -- and though I cannot even possibly estimate the variety of every character of estimation that my own simple writing may be met by, but of course I try to be cautious. As one approach towards being moderately cautious in online communications, I like to not too quickly get around to any specific manner of a point.

This characteristically rambling style that I write with, most often, in online communications -- in  that much -- this "Rambling" is, by all means, a deliberate choice of style. I do hope that my comment, in the following, will not be thought rude in all its plain sense of candor: In a simple sense, if a reader may not wish to "Stick around" until I may get to the point, in any single matter, then I would not wish to trouble the reader to continue with my writing. I do sincerely hope that that may be estimated as fair.

#TLDW ? W as in "Writing", even in writing for a consumerist web, if that's simply how the culture is, these days.

As a writer, I try to take at least a small amount of time before I may even begin to write any single thesis article. Certainly, as a participant in social networking services, in the small-media and whatsoever space-limited forums of any manner of social networking web log or microblog, I may not be able to write out an entire article, in every article I've ever written, if to simply share an observation. Furthermore, in social networking, perhaps I sometimes verge on developing a hasty style of communication, indefinitely. I'm afraid that my writing, sometimes, might be mistaken, ever, in the character of the jib in any single article, but what can I do as a writer, for the ever demanding natures of communications?

Here, sure, I had wanted to simply write an article about Help Desks -- such as to develop a metaphor as of Web as Help Desk, in a sense perhaps seldom heard of, of a range of experiences however far informed of some lengthy personal experiences with networks in free, open communications, namely the Internet Relay Chat (IRC) forums hosted by Freenode. I cannot imagine that most Freenode Help Desk supporters may be inclined to write about the experience, and happily so. Personally, I would not want to verge to far from a plain, capital sense of matters in denoting that some many people working in free/open source software development may have already subscribed, whether formally or informally, to a sort of social contract, such as the Debian Social Contract, It is not to forsake that document, that I personally have taken up a study about FreeBSD, as a component to my studies about electronics and computing, focusing on communications and designs of discrete electronics, with a big heart for all of the mathematics of the same.

FreeBSD, simply, is more truly "Free" to my point of view, contrasted to the GPL.

So, but personally I understand that there's been a veritable social wealth developed in software licensed under terms of the GPL and its numerous variations, including the LGPL and suchforth -- limited in however as to how far that social wealth ever can be practically applied. Today, the Linux kernel itself -- as the kernel of the Android platform -- is already powering the appliances of a large, significant portion of the mobile appliances market, on so many GSM and CDMA radio networks.

Personally, I'd happily leave it to the cellular phone service providers, that those aren't the only digital radio protocols around, in the universe. It's not to threaten their market share, that I observe as so -- AX.25 and so on, golly. Personally, I'm not sure if T-Mobile would even begin to consider the possibilities -- that, beyond the formal, consumer media markets -- beyond the consumer media, rather towards M2M communications, in a context of the "Internet of Things" (IoT) and the conceptual leadership of circuit element designs developed by companies such as Freescale, a division of Motorola. If pressed to a wager, I'd wager that  they -- Motorola -- may know a lot about communications in a digital domain.

Personally, I do sincerely hope that such a simple observation as that may not need to be prefaced with 20 pages of thesis article. Motorola is a company I would personally trust about their content with regards to IoT designs.

Does the reader necessarily trust me, to my observation as such? Should I worry, at that? I understand, there is a concept of Trust, in the world. I think, it is a concept that cannot all be measured in static bits. If the reader may wish to verify my simple statement, in the previous, I'm certain there's a veritable academic wealth of content published about IoT. Personally, I can recall the novelty of something so -- I would say -- odd as a battery-powered IoT bicycle lock. Innovative, somehow? but why would I want to latch my bicycle onto a battery powered device? Is it to  make it seem any more like a classier transport, but I think it is classy enough already? Sure, it'll never be as classy a Goodyear. Myself, I prefer to use non-battery-operated locks. However convenient my car's little electronic lock system might seem, I think there are some things that perhaps don't need to be driven by a microcontroller -- a matter of personal preference in bicycle locks, perhaps?

Here I go rambling, again, hm?  Personally, I've never been good at making succinct, pointed introductions in any media -- especially, if the proverbial rear wheel of my proverbial literary bicycle keeps hopping into a corporate rut, as here today -- the "Hacker rut," if I may denote that so succinctly. It's not anywhere I consider I should either want or need to be, though there's ever at least seemed to be a hint towards anything of a sense of a warmer gravity to things, around free/open source software -- a warmer sense than "Zombie cold," so to speak -- until post-2010. What happened, I don't know, and I'm not one try to to guess.

So, in and among all things under the sun, there's an operating system kernel named FreeBSD.

To the single point of this article? Thank you, world wide technical help desk.