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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android, FreeBSD, and the Golden Ticket Demistyfied

"We don't support FreeBSD officially, so you'll have to run you custom Android Studio built from source."

— [source]

With regards to applying FreeBSD as a desktop operating system, the author of this article may presently endeavor to "Skip ahead" from recounting an initial installation of FreeBSD onto an HP Pavilion PC's EFI architecture -- with a small configuration in the laptop's EFI boot-time processes, FreeBSD boots, more easily so than on the author's own older MBR/BIOS-style laptop. The author is presently running the Cinnamon desktop, augmented with an installation of Microsoft Windows 7 in VirtualBox. Although the Pavilion PC's hardware isn't completely supported in FreeBSD 10.1, but it's sufficient to maintain a usable desktop with FreeBSD -- no clutter, no advertisements, nothing but plain computing with the FreeBSD brand of UNIX.

It's theoretically possible, certainly, to develop a DITA topic repository as for the interest of presenting documentation to FreeBSD users and FreeBSD developers, in a centrally organized manner. Such a topic repository -- it might much resemble a Wiki, in style, though more centrally managed, such as viz a viz FOLDOC -- it might not be a light feat to undertake, however. Of course, there's already the FreeBSD Wiki, the FreeBSD Handbook, and the FreeBSD manual pages, all available as immediate documentation about components of the FreeBSD kernel, the FreeBSD base system, and ports available in FreeBSD. So much as in assuming that a manner of technical documentation may be of some assistance, in developing FreeBSD, the author of this article wishes to assume furthermore that a topic-oriented manner of documentation -- as may be developed onto a DITA format -- may be of some use for developing unambiguous documentation with regards to applications of FreeBSD. Of course, if there may be some disagreements about exact topical labeling and depth of overall content, maybe it would be only a "Paper project," after all.

So, while the author of this article considers that it may be useful to write more documentation about FreeBSD, but the "Central DITA topic repository" model, as an idea, it may not seem as immediately feasible as much as it may seem immediately ideal to an overview of FreeBSD.  Instead, the short and no doubt in-a-populist-light "Odd" notes at this web log may have to be sufficient, for developing so much as a stub of "New" documentation.

What's to denote, "Newly" about the Android operating system? It's an operating system applying a Linux kernel -- different to other UNIX operating systems, and different to even the Linux desktop operating systems, in some ways. The Android Operating System features some components developed by the Google Android project, some of which components are distributed individually in the Google Play Services package for Android. No doubt, Google is the primary commercial institution developing the Android platform, but there is some development support available from individual vendors and developer institutions, furthermore, such as with Samsung.

The Android operating system may be meaningfully contrasted to any number of other mobile operating systems, such a BlackBerry 10 and its QNX baseline, or iOS mobile. The Android operating system, in itself, is not all of the Google Play Android App Store, but certainly there's to one of the primary incentives to develop with Android -- as towards any possibility of developing an income from software development, moreover in software development applied onto the Android platform. Of course, as with many things, a topic of Android development may not stay forever contained of its own definition -- entailing, naturally, concepts such as of build automation, software distribution, and later issue tracking.

The author of this article would not propose to raise a barn about Android, without first denoting that someone shall have to shovel out the stalls -- as in a metaphor onto Farmville, if not a metaphor to actual farming -- albeit, at some risk of trivializing the interactions with Android users, in the metaphor, perhaps moreover a risk of trivializing any nature of farming. Android users being individual persons, there's certainly much that can be said as to how provide effective customer support in the Android marketplace.

It might seem to be of a different kind of  media than of a typical commercial support counter, but -- in being fully aware of the shovel and the stall, so to speak -- it may remain a  manageable endeavor, to provide customer support even to any very demanding customership in the Android marketplace.

One chooses one's metaphors carefully, when choosing a metaphor with a bit of pith to it.

Could it be, then, a glimmer of the much sought after "Golden ticket," that it is possible to develop an Android application on the FreeBSD platform? It  may not be the entry pass to all of Willy Wonka's own private theme park, but perhaps it may be worth a sincere synopsis at least.


[Article Draft Nr. 1]

Outline for Article Drafts Nr 2+ : Resources

• Library (Literal)
• Safari Books Online [www] (fee-based service)
• Google
• Baseline Support
• Java [info]
• Linux Emulation [info]
• USB [info]
• If YouTrack: 
• HTTP Server - Apache HTTPD, Nginx, or other
• Java Servlet Engine - Tomcat, Jetty, or other
• See also: Appserver Jails Howto
• Android Developer Tools
• ADB [port]
• Fastboot [info] [port]
• Simpleperf [port]
• Android SDK [patch]
• Bundled with Android Studio
• Available separately for ADT and other toolchain applications
• Android NDK [?]
• May not be needed for all Android development projects
• Linux emulation (?)
• Vendor-Specific Developer Support - Android Developers
• via Samsung
• via LG
• via HTC
• ...
• Documentation Tools
• Emacs
• DITA Open Toolkit
• DocBook
• IDE Integration for Android Development
• Android Studio
• See also: Android SDK
• Android Developer Tools (ADT) and Eclipse IDE
• See also: Android SDK 
• Emacs (??????)
• Android Emulators
• QEMU [info] [more info]
• See also: virt-manager [info] [port]
• ...
• Build Automation
• Gradle [port]
• Ant [port]
• Network DevOps
• Code Signing and Distribution
• Continuous Integration
• Jenkins
• Travis CI
• ...
• Change Management
• Git
• SVN
• Issue Tracking
• Trac [port]
• Request Tracker [info] [port - expired]
• YouTrack [info] [rc.d script]

Introducing GRANITENET and the FELDSPAR Platform Agnostic Object System.

As the author of this article being someone who has developed a distinct sense of interest about the logic and the existing body of work in regards to concepts of operating systems design -- moreover, a sense of interest as with regards to the effects of specific design choices in operating systems design, as of design choices ultimately resulting in discrete effects with regards to operating system applications, in any single common domain of computing, including software development, and effects in regards to application system maintenance --  the author of this article, though for some time familiar with the Debian GNU/Linux operating system, the author of this article has lately become more a fan of the FreeBSD operating system. It is this author's candid opinion that FreeBSD presents a markedly less cluttered development environment than the GNU environment of GNU/Linux systems. Not as though to meanly criticize either the Free Software Foundation (FSF) or its supporters, the author of this article is aware that operating system distributions such as Debian GNU/Linux are systems that have evolved, over time, initially from relatively small-scale origins. Considering a conceptual paradigm in which GNU tools are developed as to be modular, moreover portable with other GNU tools, moreover in which the Linux kernel itself and applications of the Linux kernel have been shaped with developments in operating system standardization -- broadly, under a heading of a colloquial definition of UNIX systems, more specifically as under the headings of international standards such as the versions  of POSIX and specifications published by the Open Group and later X/Open company, moreover as with regards to standards published by the Internet Engineering Task Force (IETF) -- the author of this article is aware that it may entail no manner of a trivial work, to develop any single, working computer system out of so many individual software components and software systems standards.  Perhaps there has been a certain degree of centrally managed organization, in the development of the FreeBSD operating system -- if not, moreover, a greater degree of flexibility as with regards to distinctions of the BSD licenses, juxtaposed to the GNU Public License (GPL) or derivatives of the GPL -- such that may result in an impression -- as to the author's opinion -- that FreeBSD is a really well organized, really uncluttered operating system, moreover very easy to apply in begining software and systems development. Certainly, such an impression is aided with the availability of so many centrally managed reference documents about FreeBSD, as in regards to the FreeBSD base system and the FreeBSD kernel.

The author would not wish to abridge any introduction about FreeBSD. This article, presently, is developed not insomuch as to make an in depth study of the FreeBSD operating system, but rather to begin to develop a set of concepts that the author has found occurring to the author's own sense of consideration, during applications of the FreeBSD operating system. The author has been operating a local area network (LAN) with FreeBSD on the the LAN gateway host, on the software build host, and on the author's primary notebook laptop, on the LAN, for a small number of months. The author has begun to develop a concrete concept of the configuration of the same LAN, referring to it then as GraniteLAN. In an architectural sense, GraniteLAN may be integrated moreover with hosts configured of software defined networking (SDN) services -- there under the heading GraniteSDN -- as to develop an overall systems development network -- with the full network under the heading, GRANITENET. Presently, the author does not wish to develop any length sidebar about the architecture of the GRANITENET design, or the design philosophy of the same. It's basically a concept for a scalable DevOps network, and a small office/home office (SOHO) network, such that may be utilized not only from GRAITELAN, but moreover that may be utilized from a mobile appliance not immediately connected to but configured for connection to GRANITESDN. In its architecture, GRANITENET would apply a distinct number of common UNIX networking services, such as LDAP, NFS, NIS, Kerberos, and -- furthermore -- RADIUS.  Though it may seem relatively easy to write about, as such, but -- in order to develop a manageable framework of so many network services, as such, and for it to be relevant in regards to applications on contemporary operating system architectures -- it may not ultimately be as easy to "Glue together," in application of so many software components. At least, it may be easy to "Put together" the concept of GRANITENET's design -- initially, as it representing a manner of a paper machine, as to apply an older phrase to the  matter -- as it entailing a design of an effectively multi-homed application of the FreeBSD operating system.

In regards to the manageability of the design and applications of GRANITENET, of course there must be a manner of a design incentive thought to exist. The author might not believe that every reader would share the author's sense of appreciation about the logical design of each of Common Lisp the Language, 2nd Edition, and CORBA systems, furthermore the Object Management Group's concepts of Object Management Architecture and Model Driven Architecture -- moreover, the portability of systems developed onto CORBA and, separately, the portability of applications developed onto the Common Language Infrastruture (CLI), the latter as popularized of the Microsoft Dot-NET and the Xamarin and Mono platforms, furthermore as standardized onto ECMA-335.

Insofar as it representing a concept of a paper machine,  the author has certainly expended some paper and graphite, in putting together a number of offline notes about the design of GRANITENET, moreover the design of a system the author denotes as FELDSPAR. FELDSPAR would represent an application of Common Lisp, CORBA, and the Common Lisp Interface Manager, as to create a bundled application development kit of free/open source software for applications of the same software and systems components. In that regards, perhaps it might seem like overmuch of an aspiring goal -- as to apply GRANITENET in developing the FELDSPAR framework, while GRANITENET is not even completely constructed, in itself, as yet. However, in retaining a sense of focus about the logical qualities of the design of each of GRANITENET and the FELDSPAR framework, it therefore remains a manageable set of concepts, at least to the author's own sense of consideration.

In beginning to describe these discrete concepts to the Internet audience, it must naturally entail a development of a literal body of documentation. Thus -- in focusing about the Darwin Information Typing Architecture (DITA) -- there is a sense of a topic repository model developed in the FELDSPAR systems design, insofar as of the present paper machine edition of the FELDSPAR systems design. The topic repository model -- in some regards, semantically -- it might resemble something of a concept like of a Wiki. Though a FELDSPAR topic repository would be published to the Web, but -- in it utilizing DITA,l in its content source model -- it would not be immediately managed "on the web". The FELDSPAR Topic Repository model would allow for managing the body of content of a topic repository, as in application of so many DITA editing tools, multimedia content development tools, and changeset management tool such as Git -- without HTTP interverning between the editor and the filesystem. As such, perhaps it may not seem to be an immediately enterprise friendly framework, but perhaps it may be scalable outwards from its initial SOHO friendly design.

In beginning to document this design, in a digital format of text, the author of this article wishes to make reference -- immediately -- reference to MARTE, specifically MARTE 1.1, furthermore to make reference to the DOAP RDF schema. Surely, it may be possible to develop a great amount of semantic sugar, in application of such normative specifications. Presently, the author wishes to recommend a concept of software platform, in an abstract sense, as may be extended to subsume concepts both of operating system platform and of toolchain architecture, furthermore as to provide a sense of structure about application components commonly referred to as libraries -- then to include the DOAP RDF schema, as to develop a documentation framework with which software developers may be able to make consistent, ostensibly convenient reference to all points of upstream software distribution, for any single software component.

Towards developing an initial usage case to this sense of structure in software and systems: The author of this article has begun to write a small series of notes, in the author's own Evernote notebook, as to begin to develop some normative documentation towards an application of the Enlightenment Foundation Libraries (EFL) and the EFL WebKit integration, namely towards developing an EFL port for the Common Lisp Interface Manager (CLIM) as well as extensions for CLIM, in regards to web appliations, such that would be developed as for application at least onto FreeBSD, Linux Desktop, Android Mobile, and Microsoft Windows Desktop operating system platforms.  Perhaps it aspires as towards a comprehensive design, to be thorough in regards to development and support of operating system applications.

Though the author is furthermore interested about some concepts of microcontroller design, reprogrammable computing, and the history of the infamous Lisp Machine, but perhaps it may turn out to be a manner of a fortuitous effort, to begin with regards to applications of existing microprocessor achitectures and existing operating systems, specifically beginning at the manner of a colloquial UNIX-like framework developed of the FreeBSD Project -- furthermore, as FreeBSD being extended in a small number of by-in-large domain-special FreeBSD distributions.

So, that would be towards an unabridged introduction.

In focusing immediately towards applications of the EFL toolkit, there is immediately a concern that occurs as with regards to illustrating the toolkit's software components and software component depencencies, as towards any single distribution of the EFL toolkit -- in a sense, as towards any single distribution of a bundled set of EFL toolkit components, whether immediately with or without the EFL WebKit integration, and finally in a distribution to any single operating system platform, in application of any single toolchain architecture. This would be essentially orthogonal to -- but, in a sense, essential to -- the development of a CLIM port for EFL.

The author proposes to develop a model for each of the following concepts, in extending the MARTE 1.1 Profile for the UML metamodel:

• Concrete Computer Machine Architecture --  immediately, perhaps extending of the Detailed Resource Model defined in MARTE 1.1
• e.g. as in reference to:
• The FreeBSD sysctl property, `hw.model`
• Compiler optimizations as may be specified in FreeBSD /etc/make.conf and/or FreeBSD /etc/src.conf
• Machine architectures in Debian GNU/Linux
• Machine architectures in the GNU Compiler Collection
• Abstract Software Platform -- likewise, perhaps extending of the Detailed Resource Model defined in MARTE 1.1
• Concrete Operating System Platform
• Concrette Toolchain arhitecture
• e.g. MINGW 
• Subsumes: MINGW x86-64
• Abstract Software Application and correspondingly, Abstract Software Distribution, in a noun sense of the latter term
• Software Distribution/Application model on a FreeBSD operating system
• Software Distribution/Application on a Linux operating system
• Software Distribution/Application on a Debian or Ubuntu GNU/Linux operating system
• Software Distribution/Application on an Android Operating System
• Software Distribution/Application on a Microsoft Windows operating system

Orthogonally, it is the author's hope that the resulting UML profile models will be compatible onto the CORBA Component Model -- such that, in a sense, may complemented with a UML profile model extending of the concept of abstract software application, if not moreover integrating a manner of a system for software distribution in regards to CORBA components, there certainly making reference to OSGi and also Maven.

That being so, then how may the author propose to publish a UML profile model, in any vendor-compatible regards? The author proposes to apply Modelio, and to publish the UML profile models finally as serialized XMI. The author furthermore proposes to apply the respective UML profile models, in development of a manner of a component metadata database, there integrating the DOAP RDF schema and some manner of a web publishing model for presenting the metadata database, in any managed manner, online. The DOAP RDF integration, in itself, may entail a development of an extensional RDF schema, moreover an application of some existing tools for RDF graph modeling in Common Lisp.

Of course, there is a sort of a boostrapping dilemma, in such design. The author proposes to address the bootstrapping dilemma, in -- albeit, perhaps in something of a expressly nolinear sense -- but in an overall iterative sense, however. In such a sense, the author does not propose to specify that the design of the RDF application would wait on the design of the project-oriented management information system (Project MIS). The RDF application must wait, however, for the design of the final component metadata schema.

Towards such an application of RDF, the author wishes to comment towards a sense of applying Common Lisp as a data system feature, within a data programming system, there closely and comprehensively integratred with the underlying operating system. The author proposes to limit this specific design to the FreeBSD operating system,  moreover to focus about a small number of individual, concrete components such as already developed as and for individual Common Lisp implementations. The goal of this aspect of the design, to the author's opinion, the goal is to support software systems development with software systems development and documentation. In such a regards, perhaps it might seem like a manner of a DevOps concept, however developed of a popularly unconventional framework

The RDF application, specifically, it may be developed as to extend of an XML Schema Datatypes implementation. As in a manner across the XML Schema Datatypes Implementation, it may be integrated onto a data persistence model for RDF, there to apply a HypersonicSQL service as a data storage service.

If there may be a rhetorical question, such as, "Where to begin, next?" the author prpoposes to continue with the development of the UML profile models, as denoted herein.

FreeBSD Base System Upgrade - How To - and a question, DITA and FreeBSD ?

The FreeBSD Handbook is a really helpful resource. It contains a lot of really well organized information -- certainly, information that may be useful for FreeBSD system developers and system maintainers -- clearly, in a format of documentation written by authentic experts about the FreeBSD Kernel and broader FreeBSD Base System -- no imitations about UNIX expertise, in the FreeBSD handbook.

Towards rebuilding a FreeBSD operating system on a local area network -- such as for compiler optimizations, viz a viz /etc/make.conf, and for upgrading the operating system to a newer version, as for instance in upgrading from FreeBSD 10.1-RELEASE to 10.2-RELEASE -- there are a few references that would be useful, in the FreeBSD handbook.

As to augment the existing documentation, I'd like to add a few small annotations -- to highlight a small number of concepts addressed in  the conceptual topic repository of the FreeBSD handbook, and in an annotations sense, to add some augmentative information -- as follows

• Building and Installing a Custom Kernel 
• Concept: Kernel configuration
• See also
• Shell command:  `sysctl -n kern.conftxt`
• Manual page config(5)
• Ed. Notes - Misc
• TBD: Cross-compiling the FreeBSD kernel (see documentation)
• TBD: HOWTO FreeBSD Kernel Configuration GUI
• See also: GNU/Linux kernel - `make menuconfig`, `make xconfig`, ...

• TO DO: Produce an index of all kernel configuration parameters noted in the FreeBSD handbook

• Rebuilding World
• Concept: FreeBSD Base System
• Ed. Notes - Misc.
• See also: Previous link, as with regards to FreeBSD kernel configuration
• TBD: Configurable parameters of the FreeBSD base system build
• TBD: FreeBSD Base System Configuration GUI
• See also: Poudriere; Augeas
• Note: Licensing terms of FreeBSD base system components 
• Note: Concepts, Licensing and Software Distribution
• TBD: Cross-compiling the FreeBSD base system
• TBD: Issue tracker integration
• See also: Debian `reportbug`
• Tracking for Multiple Machines
• Concept: Build set
• Common features:
• make.conf
• src.conf
• networked filesystem configuration (e.g. NFS)
• Recommended feature:
• Test machine
• Application:  Integration testing for compiled base system and kernel
• Optional feature:
• Change management shared files
• NIS/YP - see following notets 
• Concept: Toolchains
• Ed. Notes - FreeBSD Toolchain
• See also: Following notes about make.conf, src.conf
• Concept: Networked filesystems
• Ed. Notes - Networked Filesystems
• Juxtapose to: Block-level filesystems; Virtual filesystems
• See also: Network File System Service
• Bill Swiggle "Network File System (NFS)". ed. Tom Rhodes. FreeBSD Handbook
• mount_nfs(8). Manual page
• See also: Network Information Service (a.k.a YP)
• "Network Information System (NIS)". FreeBSD Handbook
• Hal Stern, Ricardo Labiaga, Mike Eisler. Managing NFS and NIS, 2nd Edition. O'Reilly (2001)
• See also: LDAP Directory Service
• Dag-Erling Smørgrav. Pluggable Authentication Modules
• Toby Burress. LDAP Authentication
• See also: Certificate Authority Service
• Setting-up a Simple CA Using the strongSwan PKI Tool. strongSwan documentation
• strongSwan 5: How to create your own private VPN. Zeitgeist. web log
• See also: Wireless Networking Services and WPA2-Enterprise Wireless Authentication Services
• Marc Fonvieille Loader and Murray Stokely. "Wireless Networking". FreeBSD Handbook
• HOWTO: WPA2-Enterprise with FreeRadius. FreeBSD Forums
• "FAQ." FreeRADIUS Guide
• See also: "Dynamic Host Configuration Protocol (DHCP)". FreeBSD Handbook 
• Advice: For each network client configured to obtain its IP address via DHCP, the DHCP server may be configured so as to reserve a specific IP address for each network client, as per the MAC address published of the connecting client's network interface. Each such reserved IP address may then be applied in the NFS configuration, on each NFS server and/or the NFS client.
• Alternately, if a network is configured with static IP addressing, each IP address, network mask, and router address may be entered manually at each respective client machine.
• See also: Histories of UNIX(R)
• See also: Andrew Filesytem (AFS)
• See also: Zettabyte Filesystem (ZFS)
• See also: Filesystem in Userspace
• FUSE: FIlesystem in Userspace. web site
• FUSE Module. FreeBSD Project Wiki
• See also: GlusterFS
• GlusterFS. FreeBSD Project Wiki
• Coyle, James. ZFS and GlusterFS network storage
• Gluster. web site
• Installing GlusterFS - a Quick Start Guide

• Ed. Notes (add'l)
• TBD:  Handbook-wise documentation about files /etc/make.conf and  /etc/src.conf
• Concept: Toolchains
• Concept: Machine-specific optimizations 
• e.g utilizing SSE machine instructions on later Intel architectures
• See also: 
• LLVM
• Manual pages
• make.conf(5)
• Context: all system builds, including ports, kernel, and base system
• src.conf(5)
• Context: kernel and base system (?)
• /usr/share/examples/etc/make.conf
• /usr/src/share/mk/bsd.cpu.mk

Orthogonally: Though I cannot believe I'll ever be able to sell the FreeBSD project about using DITA, but it's "A thought," though.

The FreeBSD Handbook, by in large, already serves as a topically focused -- and very usefully detailed -- reference manual about the FreeBSD operating system. As a knowledge resource, the FreeBSD handbook very much "Holds its own," as furthermore a manner of a reference manual.

The Handbook is published in a format like of a set of thesis documents about individual components of FreeBSD. In a DITA format, each article-like section in the FreeBSD handbook could be rendered as a DITA Topic. That, in itself, might not exactly serve towards further development of the FreeBSD handbook. However, perhaps it might serve as an aid to users and developers, as towards a manner of extensibility about the FreeBSD handbook -- at least, then, to authors whom would be both familiar with the DITA format, and familiar with the "Internals" of FreeBSD.

The overlap, in that proverbial set -- perhaps it might not seem to be any very broad kind of an overlap, at least outside of an ideal estimate, as of a hypothetical universe in which DITA is something anyone would voluntarily learn, beyond the small community of technical documentation geeks, and those of us somewhere in orbital space to the same.

The FreeBSD Handbook, in its original format, is developed onto the DocBook toolchain -- a long tried and trusted toolchain for technical documents. The DocBook toolchain is comprised, essentially, of the DocBook Schema -- in any single format, such as of a Document Type Definition (DTD) or a RELAX-NG schema -- and the DocBook modular stylesheets. The DocBook stylesheets, in turn, are available in both of DSSSL format -- for application onto SGML DocBook documents -- and in XSL format, for application on to XML DocBook documents.

Though there is a mapping -- as commonly available of the DITA Open Toolkit (DITA OT) -- for transforming DITA documents onto DocBook, but presently, there might not be an inverse mapping for DocBook onto DITA. It might be a fairly trivial matter, to semantically invert any much of the DITA-to-DocBook transformation module, from DITA OT, in defining a DocBook-to-DITA transformation. However, the question of whether and how that may be pragmatically worth it might remain to be addressed.

There's a topic that the author of this article is not willing to venture to address, in any offhand regards, at the FreeBSD forums: "Anyone else wants to use DITA to document FreeBSD?" Though the author of this article might fancy himself to be sufficiently familiar with SGML, XML, DocBook, and DITA formats, sufficient to be able to manage such a project by himself, but the social incentive of such a matter might seem to be fairly much "In doubt," as it may seem to be fairly much "Non-trivial," as a prospective effort, in numerous independent points of view.

In a manner of a rhetorical question: How would a "Proof of concept" be regarded, for a DITA transform of the DocBook format of the original FreeBSD Handbook?

It might seem to need some kind of a "Run-up time," such a project, if it could ever be a project that might be any furthermore adopted by the FreeBSD developer community. Though the author of this article, in particular, fancies DITA to be as simple as push-button editing -- except for all of the visible markup of it -- but not everyone might quite agree.

In a further juxtaposition of DITA to DocBook: In DITA, there are also the matters of content inclusion and seperately, of linking, each of which such concepts does not occur exactly in such a manner, in DocBook, not in exactly as it occurs in the syntax and semantics of DITA. Furthermore, in DITA, there is the topic 'class' attribute -- probably a very much interesting features, to those of us whom may be, furthermore, object oriented programming (OOP) geeks.

Ed. Note: ...and then there's something about "How to avoid arbitrary topics," as towards, orthogonally, towards a manner of a Wiki model for DITA or -- contrarily -- towards a centrally edited topic repository model for DITA 

It would definitely be a project applying the Java(R) programming language, to document FreeBSD with DITA. DITA OT uses ASF* Ant, for instance, in DITA OT's own build automation framework. ASF Ant is a tool developed in Java(R). Whether or not all persons editing DITA documents may prefer to use editor platforms also developed in Java(r) -- such as the commercially licensed Oxygen XML product -- and the author of this article would rather prefer to use Emacs and PSGML, candidly -- but for so much as building the finally formatted documentation, it would definitely need to use Java(R), such a project. It may be at least a convenient thing, then, that FreeBSD is really good at running Java(R) applications.**

Is that enough of an incentive, in itself? Most probably, it is not. DITA is not the hottest kewlness online, and -- candidly -- all of this amounts to anything very much unlike a hot rod sports car view of FreeBSD. It doesn't exactly become easily to a metaphor about Minetest, either -- not to game around about operating systems design. This article describes some concepts of documentation, as in or towards a manner of a developer's view.


* ASF: The Apache Software Foundation.

** It could seem almost like a kind of Digital Magic -- the efficiency at which FreeBSD runs Java(R) applications, even on the desktop. Perhaps it's rather a matter of the operating system design in FreeBSD.

Custom Build for SBCL 1.2 with Multithreading on FreeBSD 10

After installing SBCL 1.2.9 from the standard baseline package for FreeBSD 10.1-RELEASE, the *features* value is as follows:

(:ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :BSD :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS :FREEBSD :GCC-TLS :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS :INTEGER-EQL-VOP :INTERLEAVED-RAW-SLOTS :LINKAGE-TABLE :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR :RAW-INSTANCE-INIT-VOPS :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL :SB-LDB :SB-PACKAGE-LOCKS :SB-QSHOW :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)

In a a custom build, SBCL 1.2.14.32-ce739b6

(:ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :BSD :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS :FP-AND-PC-STANDARD-SAVE :FREEBSD :GCC-TLS :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS :INTEGER-EQL-VOP :INTERLEAVED-RAW-SLOTS :LINKAGE-TABLE :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR :RAW-INSTANCE-INIT-VOPS :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS :SB-SAFEPOINT :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-THRUPTION :SB-UNICODE :SB-WTIMER :SB-XREF-FOR-INTERNALS :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)

 Difference:

(:SB-XREF-FOR-INTERNALS :SB-WTIMER :SB-THRUPTION :SB-THREAD :SB-SAFEPOINT :SB-FUTEX :FP-AND-PC-STANDARD-SAVE)

In the custom build, I'd enabled the :SB-XREF-FOR-INTERNALS feature for purpose of debugging, the :SB-WTIMER, :SB-THRUPTION, and SB-SAFEPOINT features for purpose of testing, and initially just :SB-THREAD for multithreading. The build did not complete.

Without :SB-FUTEX enabled, the build might fail/loop/freeze during the build's integrated testing. When the :SB-FUTEX feature is enabled along with :SB-THREAD, then SBCL compiles successfully on FreeBSD 10.1.

#YMMV

Ed. Note: This has since been addressed to a comment in the FreeBSD Bugzilla database, at Issue nr. 199055

Towards a DITA OT Port for FreeBSD -- But First, The Larch

Corresponding to a beginning of a development of a personal business plan, formally starting today, I've set aside my  own edition of the [plug start] Samsung Galaxy S 8.4 Tablet -- an Android tablet -- and its seat-friendly, tabletop-friendly, all-around outdoors-friendly Griffin All-Terrain case [plug end] -- furthermore, leaving aside the Evernote app -- likewise, to sit down at my FreeBSD notebook -- for a short time -- indoors. It's a kind of a "Pivot day," in my own small, individual corner of the world. I've subscribed to Safari Books Online, and have begun to develop an ongoing books list.

In beginning to read one item in that list, I've queued up what is my first book to read about the Darwin Information Typing Architecture (DITA), in my own Safari books queue, namely the text: DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA.

Corresponding to that new books subscription, yesterday I'd begun developing a draft edition for another 'blog article -- that article, focusing about DITA, as in developing a concept of DITA architecture and DITA in applications. That was in using the Blogaway app (Pro edition), on my tablet.  I'm afraid it may as well remain in an unpublished draft edition, that article. Candidly -- in no short time after I've signed up with the Safari Books subscription service and begun reading about DITA -- presently, it's developed from an academic pursuit into a project idea. Likewise, it's such that I'd like to share about, as a project idea.

Of course, a project would not be able to take up a life of its own, in such short time. Beside the introduction that I'd tried to develop, in that unpbulished 'blog article, yesterday, but in a shorter sense of overview: Personally, I have some albeit limited knowledge about technical writing -- as namely with regards to a small number of document formats, such as the DocBook SGML DTD and DocBook 5 RELAX NG XML schema. I'm fairly well familiar with XML, more broadly, as a markup format.

Previous to yesterday, I'd read a little bit about DITA. In a sense, I'd thought it seemed like a kind of a cheerful little ray of sunshine about narrative XML documentation formats, in broad -- a topic that there might not seem to be too many rays of sunshine about, typically.  Candidly, on reading only some little about applications of the DITA schemas -- furthermore, in my being familiar with a style of hypermedia markup conventions as developed in DocBook -- I was a little put-off about some of the conventions of XML syntax developed in DITA. Mainly, there are the syntax and semantics of linking, in DITA information sets -- more specifically, a small number of elements and attributes in DITA, such that those elements and attributes may serve to provide "hooks" for content replacement in DITA processing models, as I've now begun to understand-- in a sense, those confuse me otherwise. I think there's a substantial difference in how DITA develops a concept of hypermedia linking, contrasted to the primarily ID/IDREF oriented hypermedia linking model in DocBook. I don't personally find myself able to "Leave it all to the editing platform," either -- my not being able to assume any manner of an opacity about the DITA markup format -- as I'm fairly certain that I may be editing a DITA markup file in a console-based text editor, at some point in time.

So, although those features of the DITA markup schemas may be such that I may find difficult to understand -- at least, at either of a first or second approach, in study -- now that I've found more of a friendly documentation about DITA and reviewed a couple of DITA document source trees, I'm fairly certain that I should be able to learn to proactively adapt my own hypermedia knowledge to adjust to the DITA document formats, even inasmuch as with regards to extending DITA.

 It's on that note, then, that I am still trying to write around the "Long leap" of the following tasks, as I can forsee in my own "Next nine yards" about DITA:

1. Installing Java on my own FreeBSD notebook, with work-log, notes, and documentation references correspondingly
2. Installing the DITA Open Tooolkit Tools onto the same notebook, likewise with a set of corresponding notes and references
3. Likely beginning at least a local project for creating a FreeBSD port of DITA Open Tooolkit. This task, ultimately may entail a communication and further coordination with the FreeBSD Java(R) Project. As such, it's nothing I may approach in any of a too casual regards. Not to say overmuch about my own opinions of Oracle's style in commerce or software development -- however contrasted to the novel goodwill style of approach, as originally developed by Sun Microsystems -- I think Oracle's left me with a little bit of a bad impression, as to Oracle's position reportedly ever disfavoring developments in free/open source software (FOSS) namely in defense-oriented projects, and perhaps Oracle's own lack of information, as such, candidly. 

So, personally, I'm not a big fan about Oracle, and I'm not altogether certain if there is any broad Java developer community, any more, outside of Oracle ... and  FreeBSD, and a small number of enterprise web portal projects. The vibrant community that had developed around Java, during Sun Microsystems' management of the development of the Java programming language -- would it be too naive, to draw a metaphor of fracking, as for how that changed when Oracle acquired Sun?

The Oracle Java(R) launcher thing on Microsoft Windows 8.1 -- though it's cute, certainly -- it doesn't really change that impression, so much, not to my own point of view. Candidly, I still expect Oracle to be the monolithic corporation largely focused about a database platform, such that I've -- for a long time -- estimated of Oracle as a company. I don't think it makes any less of an Atlas-like shadow, with Oracle having acquired Sun. With Oracle now having demonstrated their own obvious lack of information with regards to FOSS and defense systems software, I might wish to trust Oracle to be moreover a Blind Atlas -- very worrisome, I think, worrisome if Oracle would set about to "Make New The Things."

So, knowing of a particular manner of a corporate monolith as such, looming up a little ways northward in California, and with some much of a knowledge of a broader world, I'm afraid I'm unable to join in the local Cool Team Parties. Even in avoiding any manner of a too locale-centric manner of a perspective about software development, but it still kind of "Creeps me out," about Java(R), if Oracle is really all the Enterprise as may I candidly estimate it to be.

If it may be possible to limit one's owns views to a sense of plainer principles, however -- inasmuch, to not make overmuch of a consideration as with regards to superstitions -- sure, Oracle might not be  all of the scarily opaque commercial software institution that I might think of it as. Focusing if simply on the ongoing free/open source licensing of any products previously developed or adopted by Sun Microsystems -- such as Berkeley DB, for instance, in its free/open source licensing options -- there's a matter of software licensing, orthogonal to any company's own apparently political positions with regards to software development models.

Thus, there's a foot I can find, in my own sense of knowledge about software now licensed by Oracle -- a foot, at which I may be able to disembark from my own concerns with regards to Oracle's policies. If it could seem as though Oracle could become such as, "Like Old Microsoft, but a thousand times worse," there's what I'm worried about. Regardless, the free/open source licensed by Oracle as free/open source software, that much of software might endure any such shift -- as much as of any free/open software licensed originally by Sun Microsystems.

So, in something of a sense of an organizational view,  maybe the goodwill "Vibe" that Sun developed could be just enough that it may endure even the acquisition by Oracle -- however far any developers and managers who would've been the parties directly developing such goodwill, and about a programming language moreover, however far "The Java Original Team" in and beyond Sun, may  have been put off and away from Oracle.

If I'd thought as though the film TRON: Legacy may have been all of a metaphor about Apple, perhaps it could as well be a film interpreted as if about any other Silicon Valley empire of an enterprise -- Oracle, perhaps as like a CLU character nearly making Java break out so much that it would break apart?

I don't find myself able to ignore the apparent social implications of Sun's acquisition by Oracle -- it seeming even more worrisome, after Oracle tried to toss some mud to the US DoD, as denoted in an article once reported to Slashdot, mud as if about free open source software. The "Old Microsoft 2.o?" theme, thusly, it began in my own simple point of view about Oracle.

Clearly, Oracle "Owns" Java(R)  as a trademark, today, but -- not even after the acquisition of Sun -- Oracle certainly does not own the history of the Java programming language. Thus, there's a broader sense of context, and nothing radical, about not looking too far into the Oracle.

So, maybe there's any plan for Java integration in LLVM. I'll have some research to develop, before I myself may develop any further work about Java(R) on a FreeBSD(R) operating system. The Brand Wars not begun again, they have not.

Towards Building a Square Desktop OS - FreeBSD on the CORVID PC

Towards developing a model for graphical desktop applications on a FreeBSD operating system, proceeding in a manner by in large independent of any single, existing project, as such -- e.g. such as PC-BSD,  a distribution of the FreeBSD base system, with distribution-specific extensions, catered towards desktop computing -- simply, in beginning with the FreeBSD base system, I've been focusing on developing at least a single  "Known good" configuration.  Before proceeding to describe such configuration, some disclaimers may be in order.

This is not as though to make any manner of a radical response to the emergence of Linux distributions, in any of mobile, desktop, and network service computing platforms. Neither is it as though to try to "Steal thunder" from any of the commercial institutions developing, each, their own proprietary operating systems -- such as Microsoft and Oracle, inasmuch as Oracle had acquired Sun Microsystems, thereby acquiring commercial  distribution rights for the Solaris operating system. Simply, it's of my own small effort towards extending of any body of existing work, ultimately towards developing any new software products, in developing a multi-platform desktop computing framework out of the FreeBSD base system.

In developing my first FreeBSD desktop installation, which I'm applying in , writing this article, I'd begun with FreeBSD 10.1-RELEASE, installing the operating system from the UEFI-enabled DVD distribution. The laptop to which I've now installed FreeBSD, it's an HP Pavilion x360 notebook -- with touchscreen. The same notebook uses a UEFI firmware stack, and so of course its internal hard disk drive is formatted according to the GPT disk format.

The installation was made not without some initial difficulty. It being a dual-boot installation -- my wishing to retain the Microsoft Windows 8.1 Operating System (OS) in its installation as created by the Original Equipment Manufacturer (OEM) and later updated of my own application installation and system configuration efforts -- so, previous to the FreeBSD installation, I'd used Raxco PerfectDisk in its boot-time and normal disk defragmentation modes. After some small effort, I was able to create enough deallocated free space on the laptop's internal hard disk drive, sufficient to resize the NTFS partition, thus creating a disk space in which I could install FreeBSD. Although the Microsoft Windows 8.1 system information utilities had reported that there was a substantial amount of free space avalable on that same NTFS partition, initially, but -- perhaps, ironically -- something among the OS kernel and/or userspace applications was persistently writing a small number of file data blocks at the very end of the NTFS partition. That made it more or less impossible to install a secondary operating system.

The Microsoft Windows 8.1 built-in defragmenter was not sufficient for moving those file data blocks into any space nearer to the beginning of the partition. With a small further effort, however, I was able to apply Raxco PerfectDisk. then the Microsoft Windows system management console, to gradually create a filesystem area of approximately 175 GB of deallocated disk space. 

After rebooting, then making some small changes in the BIOS-like configuration screen on the laptop -- there, enabling legacy BIOS mode, and also enabling the processor's virtualization features, for later application with regards to QEMU and VirtualBox -- thus, I prepared the laptop for UEFI boot to FreeBSD.

I booted the PC, initially, from the FreeBSD installer DVD. I created a FreeBSD root UFS filesystem and a FreeBSD swap partition, the latter having approximately one gigabyte more of data storage space, juxtaposed to the laptop's installed RAM, to a total of approximately 9 GB swap, approximately 168 GB UFS filesystem, all FreeBSD format.

Following the installation, I rebooted the PC. On the HP Pavilion PCs, the  "Esc" key is the "Hotkey" for activating the legacy BIOS menu during Power-On System Test (POST).  Although the FreeBSD UEFI configuration on my notebook requires a manual input at boot time -- namely as in order  to select the FreeBSD UEFI bootloader, presently the second bootloader listed in the "Legacy" boot menu -- that small mater does not seem to be any sort of a notable inconvenience, to me.

Thus, after the installation, the PC made its "first boot" to FreeBSD.  Subsequently, I installed the BASH and BASH Completions packages and changed the root user's shell to BASH. Then, I added a non-root user -- UID 1000, towards a convention for non-system user IDs, as applied similarly throughout Debian operating system distributions. I then used 'scp' to copy my default screenrc, bashrc, BASH profile, and bash_logout "Dot" scripts from my LAN gateway onto the notebook, under the non-root user's home directory. Then as the root superuser, I made symbolic links to those files, from under the root user's home directory. Thus, I had installed a baseline terminal environment. I've since installed a small number of additional utilities -- mmv, uemacs, and xstow -- largely for sake of convenience at the shell command line.

Separately, I've installed a small number of developer tools -- initially, Git, SVN, the SVN2Git bridge, and CVSPS. My being by in large comfortable with the Emacs text editor, I've also installed Emacs 24. I should be updating my dot-emacs directory from my own LAN-local Git repositories, shortly. These packages, in particular, I would denote as their being elements of a developer's profile for the FreeBSD PC.

Following that, I've installed X.org, Xinit, a desktop manager (SLIM), a desktop environment (MATE) and a web browser (Firefox, though I'd tried out Chrome and Opera on FreeBSD initially). The installation of the desktop environment, itself, also entailed an installation of a terminal emulator, a calculator, a text editor, a file manager, and some other relatively lightweight utilities.

Of course, throughout this process -- even as soon as installing BASH -- I've had to make some small configuration changes on the host, manually -- such as for some various changes onto /etc/rc.conf, /etc/sysctl.conf, /etc/fstab, and even /etc/udevfs.conf. such as in regards to SHM support for some of Firefox's HTML5 functionality, and in regards to dependencies on fdescfs, dbus services, pty services, etc.

In the process of trying out the Opera browser on FreeBSD -- namely, at Opera version 16, in its present release, as published via the FreeBSD baseline package repository -- I'd also installed the Linux C6 32 bit emulation for FreeBSD.  Subsequently, I'd tried to run Opera version 30 in its Linux (amd64) edition -- then, subsequently, a 32 bit distribution of Opera Version 30 for Linux. Though I think it was quite nice to see that there is a 32 bit version of Opera 30 available, for Linux platforms, but -- insofar as concerning the Linux emulation for FreeBSD -- Opera 30 requires some features that, apparently, are not as yet ported into the Linux C6 32 bit emulation for FreeBSD. My being more immediately concerned as to install a usable web browser to the PC, I've installed Firefox, with no subsequent issues.

Presently, on having observed a note towards possibly developing a FreeBSD edition of Firefox OS, I might wish to wonder what specific licensing concerns there could be for redistribution of the nspluginwrapper port. Reviewing Section 7.2 of the FreeBSD Handbook, apparently there's a concern with regards to redistribution of compiled binary versions of the nspluginwrapper port. Towards a transitive concern with regards to Adobe Flash applications, perhaps a project may need to curry the favor of Adobe, itself, if to ensure that an Adobe Flash plugin might be developed for any single web browser on FreeBSD, or perhaps the SWFdec plugin could be more further supported as a third party plugin for Adobe Flash applications. Referring again to the FreeBSD Handbook, it may seem that those are the two primary alternatives available for Flash support in a web browser on FreeBSD. Perhaps, that may serve to present a concern as towards any possibility of applying a Mozilla Gecko application stack for user interactions with regards to web applications, on any manner of a FreeBSD distribution of Firefox OS.

Alternately, in a figurative sense, perhaps one might endeavor to chart a course towards the furthest side of the furthest known minor planet, Pluto, as if there to develop a by-in-large distinct web application framework onto FreeBSD, with minimal local distractions. Perhaps at such a destination, one may propose to apply Steel Bank Common Lisp (SBCL) -- for instance, in focusing about SBCL's compiler optimizations, among other portable ANSI Common Lisp implementations -- and a fork of each of CLORB and McCLIM -- of the latter, focusing on the CLX CLIM Port, in McCLIM.

The same platform could apply the upstream CLX codebase, unforked. Alternately, in any project developing such a platform, the project might endeavor to develop an implementation of the MIT shared memory extension (MIT-SHM) as perhaps towards any more of an ideal sense of efficiency in "Same-host" CLX client applications on X Window servers likewise supporting the MIT-SHM extension. Perhaps it might serve as to minimize data transfers over local socket channels for X Pixmaps, at least, if MIT-SHM may be supported in CLX. Around such a development, perhaps it might be apropos also to develop a memory locking framework for SBCL, such as to prevent password data or other sensitive user data fields from being paged out to disk from within an SBCL runtime process.

Both of the MIT-SHM and the "Unpaged RAM" features would entail something of a matter of -- if a reader may pardon the pun -- addressing memory areas in the SBCL data space. Of course, the  MIT-SHM extension might also require an integration directly with C-format XLib libraries -- thus, perhaps creating an awkward situation in which a non-C-language XLib implementation would use only a small modular part of a C-language XLib implementation. however therefore depending on more features of the C-language XLib implementation, so far as functionally depended-on by the single shared module.

The "Unpaged RAM" extension for SBCL would not require any dependencies expressly onto any additional toolkits. As well as with regards to user data security, the "Unpaged RAM" extension might be furthermore applied for purpose of deterministic scheduling in a realtime computing model applying SBCL.


Personally, I've considered reviewing the Enlightment Foundation Libraries (EFL) separately, for such an albeit unlikely project.  EFL is licensed under BSD style licensing terms. As an application toolkit, EFL moreover publishes a C interface. Although the Enlightenment DR17 window manager, itself, might be somehow difficult  to configure for some FreeBSD PC environments, but perhaps it could al work out better on mobile. EFL is used in the Samsung Tizen platform, after all. There's also EFL WebKit  -- there, to yet another concern with regards to web browsers ostensibly on FreeBSD, furthermore towards some more of a concern with regards to toolchains. EFL WebKit uses CMake.


The author is not immediately certain if any of this would be any easier to "Parse" if it was all formatted in a succinct RDF graph, instead. Perhaps it might seem "Too easy," in such succinct rendition.

GraniteStor - Design Abstract - Towards Definitions of an Abstract Application Space and a Design of a System for Applications of Generic Data Resources

Beginning of an ad hoc abstraction of the Common Lisp 'load' function, the following article endeavors to develop a sense of structure and semantics of an abstract application space, as primarily towards definitions of CORBA object services for distributed computing environments.

For a program system to be able to process any number of one or more program resources -- resources such as would represent source code or compiled object data, such as would affect the runtime execution environment of the program system, on load --  a program system must first locate the program resources.

After locating a program resource -- as whether located via a kernel fileystem service or userspace application service -- the program system may  then establish a data connection to the service by which the program resource has been located. In a manner of typical file input procedures, in an instance of an operating system kernel implementing a POSIX model for system procedures -- such as Linux or FreeBSD -- the data connection establishment procedures might be represented by the program resource establishing a file descriptor onto a filesystem resource, via a C 'open' or 'fopen' function. For accessing a program resource via a compressed archive file, alternately -- such as for program resources stored within Zip format Java Archive (JAR) files -- broadly, a data connection may be established for accessing the compressed archive containing the program resource, then any one or more archival procedures may be performed such as to retrieve the individual program resource from within the same compressed archive.  In a third example, for accessing a program resource via a trusted WebDAV service, firstly a network application session may be established to the WebDAV service, then secondly a data connection may be established for accessing the individual program resource as via the network application protocol implemented by the respective WebDAV service.

Subsequent to that a data connection would be established -- as to access a media object effectively representing the contents of a program resource -- the contents of the media object would be processed to an effect of loading the program resource into the program system's program space. Lastly, the program system may endeavor to perform programmatic operations such as would have been loaded into the program system's program space, originally from the program resource.

Orthogonal to the procedures of data connection establishment and program resource loading, then -- as specifically considering an example of accessing a program resource from  within a JAR archive file -- effectively the example may serve to lend to a sense of filesystem containers. A JAR archive file, broadly, is a compressed archive file with a specific internal archive format -- more specifically, an archive file compressed with Zip compression, secondly the archive file having a specific internal filesystem format. As a special manner of archive file, a JAR archive file serves as, effectively, a filesystem container for Java program resources. Typically, a JAR archive file may be accessed by a Java Runtime Environment (JRE) as for a purpose of  load program resources -- such that those program resources would  typically have been compiled with the 'javac' compiler of a Java Development Kit (JDK). A JAR archive file, more broadly, may serve as a container of non-program data resources, such as of configuration data and static graphical interface object data.

Aside to any manners of specific, semantic differentiation of data resources -- as with regards to semantic differentiation of program data resources and non-program data resources, as in regards to structures and applications of data resources -- with an example of the JAR archive file as a singular keynote, an abstract container model may be designed for modeling of data resources. The abstract container model, however developed, may be expressed for applications in a portable, platform-agnostic format such as CORBA IDL. In applications, the abstract container model may be implemented such as for an application to provide CORBA object services onto any number of resource types, as may include: Archive files; networked application protocols providing filesystem services; filesystem directories; individual filesystems; application-defined structures such as of ASDF system definitions, Apache Maven Project Object Model (POM) definitions, or individual software package structures.


Broadly, towards a definition of CORBA Object Services for access onto filesystems, two examples may  be considered: CORBA Audio / Video services [Han2004] and DOM 3 Load and Save [DOM3LS]. In albeit a naive sense, a CORBA Audio / Video services implementation may serve to provide an number of stream-oriented multimedia playback and control services via a networked CORBA architecture.  DOM 3 Load and Save, beyond any specific applications in the document object model, may serve to provide -- broadly -- a structured, event-oriented approach for file data processing via a networked CORBA architecture. Hypothetically, any number of extensions may be developed for applications of DOM 3 Load and Save functionality, in a manner broadly orthogonal to representations of Document objects in in the Document Object Model (DOM), more specifically extending of an event-oriented data structure processing model as developed of DOM.

In a manner of narrowing a design of an abstract container model for data resources, in focusing -- broadly -- on structured formats of individual data resources: Any single file type data resource, in itself, may be modeled as a container for persistent object data, such as may be encoded within a single file data resource.

Hypothetically, an object storage filesystem may be defined, such that the object storage filesystem may store and retrieve persistent object data in a format specifically of object types and object data fields -- in a sense, focusing on storage and retrieval of object data structures such as of DOM Document objects, not expressly focusing about storage and retrieval of object data serialization structures such as files, filesystems, and file archives.

In an implementation onto an existing operating system -- inasmuch as that an object storage filesystem may be implemented onto an existing filesystem architecture -- a filesystem architecture such as may be underly an object storage filesystem may need not be -- in itself -- defined as to be expressly "Pretty printed" in any single structural list. If an object storage filesystem may present at least a human readable view of objects stored in the object filesystem -- not either in obviating concerns with regards to data access rights -- then any object data services, such as may be defined in an implementation of an object storage filesystem, may store and retrieve data onto an operating system's underlying filesystem device, using any single baseline file naming scheme and any collection of specific file formats such as may serve to allow for an efficient storage and retrieval of object structure data, in the respective object data services.

Not as though to propose to reinvent an operating system, an object data storage system in Common Lisp -- when implementing a CORBA architecture in Common Lisp -- may effectively "Borrow" the CDR encoding format implemented in CORBA IIOP. Perhaps a CDR implementation, furthermore, may be refactored for marshalling and unmarshalling of object data onto a filesystem -- juxtaposed to marshalling and unmarshalling of object data within a network peer services architecture.

So, hypothetically, a single CDR Serialization service may be defined, such that the CDR Serialization service would effectively serve as a channel encoder/decoder for object data as may be stored onto persistent media.

This is not as though to recommend that a CDR Serialization service would be applied as if to instantaneously persist data structures and values for every object initialized within a program system. Certainly, in a hypothetical embedded computing platform, the figurative tires of a serialization service might wear out a figurative NAND/NOR road, if the figurative tires would be run on the figurative road, too frequently. That is to denote, as by way of an analogy, that a memory technology device (MTD) may allow for only a limited number of store/load cycles for data stored in the MTD's NAND/NOR firmware, without degredation of the MTD's storage capacity -- aside to any nondeterministic metaphors as of road maintenance for MTD applications.

So, in designing a model for a program system suh as may implement an object data serialization service -- as may extend of a conventional filesystem service -- a distinction may be drawn between runtime data structures and persistent data structures. As one possible juxtaposition: A distinction may be defined in a sense of a failover view, such that If a set of runtime data strutures would not be recorded onto persistent media, that it would not irreversibly degrade the performance of an application, if the data structures would be effectively "lost" as due to termination of a processing thread, if not a complete system power cycle in the underlying computing platform.

In another sense of a juxtaposition of persistent and runtime data structures: A discrete set of filesystem data records may be processed by an object storage service, such that a persistent data structure may be initialized of the contents of the filesystem data records. Subsequently, the filesystem data records may be updated -- certainly, updated in a transactional regards -- updated for any changes in any corresponding data fields within the persistent data structure. A persistent data structure, in itself, might make reference to  any one or more runtime data structures, such that would not be recorded onto a persistent filesystem media, though referenced by a persistent data structure. In a description of such a view, it might furthermore be noted that an object storage service may be defined as an abstraction of table-oriented data storage models, such as may be implemented with regards to portable SQL.

In a sense with regards to storage models for tabular application record structures, perhaps the former might be juxtaposed to a more generic file-oriented data storage model, as in that a tabular storage model may serves to add any set of structures for  tabular storage of persistent data records, essentially specializing a generic persistent storage model, in the abstract application space.

Towards a further juxtaposition of runtime data and persistent data, a juxtaposition may be presented as with regards to an orthogonal concept, broadly, of how applications process data. In albeit a broad case study of a hypothetical application, Bazomatic, the Bazomatic application may store a certain selection of data values into a structured format in persistent data storage. On processing of any set of persistent data values as thusly stored, the Bazomatic application may create any discrete number of relational data values in the Bazomatic application runtime data space, as for purpose of maintaining a sense of data structure among the data values originally stored into persistent data storage. The relational data, as such, may need not be stored expressly into the persistent data files -- the relational data being represented, in an application-specific manner, as though in implicit relations among persistent data values, in the structured record format of the Bazomatic data storage model.

Beyond a view with regards to data record formats, moreover an application program may create any number of runtime data values as to represent, structurally, any specific set of qualities of system devices such as may be accessible to an application's runtime environment -- such as of individual keyboard, mouse pointer, touchscreen, LED, printer, or other input/output devices.

Of course, with regards to data presentation, an application may likewise store any relatively small number of persistent session data values, within any single computer system user's own data storage space -- such as of window positions, in an application session of a graphical windowing environment. A system user's own persistent session data may be applied within an application system, as for purposes of configuration of application session properties, across any single application session durations. 

In a manner more functionally fundamental than the data presentation systems of any single computing environment, a computer system may furthermore present any number of persistent data storage devices and network data communication interfaces, in a manner internal to the computing system's own runtime operating system. In regards to network data communications interfaces, orthogonally, the author wishes to make a note with regards to the Netgraph architecture implemented in FreeBSD. If the Netgraph architecture may be extended for direct access to persistent data storage devices, perhaps such extensions may furthermore make reference to the FreeBSD virtual process jails model -- as perhaps towards an altogether abstract model extending of real implementations of services for data storage and data communications, within a contemporary computing environment.

Orthogonal Concept: Offloading Filesystem Handling to Kernel/Userspace Filesystem Adapters - FUSE

An outline for any good' ol' "TL;DR" synopsis

• FUSE: Filesystem in Userspace
• GNU toolchain
• Linux Kernel - VFS Drivers
• FUSE Support in FreeBSD
• FUSE Filesystem [FreeBSD Project - Wiki]
• Filesystems on FreeBSD [FUSE Project -Wiki @ SourceForge]
• Ports - Active: Fusefs [FreshPorts Search]
• Highights for multi-boot enviroments - fusefs
• fusefs-ntfs
• fusefs-exfat
• fusefs-ext4fuse
• With FuseFS configured in a [host, hosted virtual jail, or a Bhyve VM environment], applications may access local/remote filesystem resources via normal kernel filesystem protocols. 
• FUSE allows for implementation of filesystem protocols, with the underlying filesystem services being functionally transluscent to the filesystem service client
• Contrast to: ZFS

PF It Was, or: Addressing the Shape of the Times in Liberal Abandon

Recently, I've begun to study about the architecture and configuration methods of the FreeBSD base system in FreeBSD 10.1. It's a study that, personally, I am not one to want to rush about. Though, of course, I think there may be something of a marketing value in the "Hot rod effect", and I think it would be grand if one may be able to provide a fully configured FreeBSD operating system for support of the further development of the state of the art -- whether or not as if "all by myself," certainly an unlikely state of the matter -- but presently, I'm more interested in understanding the base system's architecture, to a point of at least being able to develop further documentation, if not to develop some application tooling for administrative support.

Juxtaposing FreeBSD to another contemporary operating system: Though I am at least passingly familiar with the management layer of the shell interface to the QNX operating system with Cisco's own added bling-- such that essenitally comprises the contemporary Cisco IOS -- and I understand that Cisco hardware finds a wide commercial application, I think that there's a greater discernible value of FreeBSD, in that there is a lot more of architectural knowledge available, and available to the broader public, of the design of the FreeBSD base system. Furthermore, the altogether positive experience of applying FreeBSD in any single network-local, host-local, or otherwise discrete implementation -- in my own experiences, thus far -- it only adds to the goodwill due to the FreeBSD Project. Although, in a classical commercial sense, the FreeBSD Project might not be, in itself, all of a for-profit institution, but then again, neither is the typical university.

With regards to designs for application tooling, I'm afraid that my own ideas -- in such regards -- may seem a little unconventional. Albeit through not any manner of any formally institutionalized educational process, I've learned a fair lot about the design and applications of the Common Lisp programming language, over some long years of study. Though perhaps I am not personally of any manner of an outgoing character about Common Lisp programming, as though it was a social endeavor, but I am quite well impressed of the design of Common Lisp the Language, 2nd Edition (CLtL2), in and of itself -- moreover, the design of the Common Lisp Interface Manager (CLIM) -- as both representing, fundamentally, theoretically complete programming systems -- closed in a sense of turing completeness. Of course, as I've not studied the language in any manner of a formal institutional context, tthen perhaps my own choice of vernacular about the Common Lisp programming language might seem a little unconventional, if not plainly obtuse, to some points of view. Thus, I am of an opinion that I should not ever wish to be outgoing about Common Lisp, whether as it being a programming language, a development environment, or a community feature. I should not ever wish to rain on anyone's parade -- whether socially or personally -- wherever the development of Common Lisp, as a software programming environment, may be proceeding to -- when clearly, it must be a very well academically sustained programming environment, already. This, I write all with  a grain of salt -- as for the simple nature of irony as a literal concept -- moreover, considering as that I am a bit stunned if a programming language can be academically supported, and yet nearly absent of obvious commercial applications. Perhaps it is enough that CLtL2 is -- I am quite certain -- an uncommonly well designed programming language -- thus, that it could occupy any such of a hypothetically precarious place in the state of the art. So finally, I've been able to write something squarely about Common Lisp, this must be something of an odd day therefore.

Without venturing onto an orthogonal thesis, as with regards to the design of the Common Lisp Object System, or the Common Lisp compiler in any single CLtL2 implementation, presently I'm of an impression that I have spent a portion of time well, in this evening, that I've been studying in this short time, as about the design and application of the PF packet filtering framework -- as was implemented in OpenBSD and later ported to FreeBSD. [Handbook s. 30.3] in two instances of its documented systems lineage. The structural archaeology of software systems -- aside to any manners of discussions as with regards to principle and practice about intellectual property -- there would be another orthogonal thesis, if there was the time for it presently. There might be something that one could wish to add about manners of nonrepudiation, at that.

In studying, this evening, about the effective systems design developed in PF -- the latter, in as the PF kernel modules and shell commands have been ported to the FreeBSD base system -- studying moreover, not inasmuch for an application to any manner of a one-off shell script, but rather, studying the documentation as for to understand the nature of the effective object system defined in PF, moreover to understand how to configure, implement, and debug PF services on a FreeBSD host -- of course there might be a small number of spinoff projects, to accomplish even this small endeavor. 

Beside the documentation published about PF in the FreeBSD Handbook, I've found that I've needed to make reference furthermore to the FreeBSD manual pages, as in order to understand -- in a sense, more thoroughly than I had found myself able to understand, immediately, from the handbook itself -- how it works, in no particularly proprietary regards. If there may be something of a sense one mightt learns about how to understand a software design, from reading the documentation about a software system, but I would not wish to present any orthogonal thesis, here, as with regards to any manner of a metasemantics of technical documentation. If I was not able to completely understand how to apply PF, from the handbook alone, it might stands to reason that I may wish to write some more documentation about it, to put together my own observations into any single literary work. It is not whatsoever to make a critique of the FreeBSD Handbook. As much as the FreeBSD Handbook might be observed to be, in itself, a part of the essential documentation of the FreeBSD base system, moreover that the documentation about PF, in the FreeBSD Handbook -- to my understanding -- it provides an essential keynote towards the broader documentation about PF, in its present state of implementation, but I am not one to complain about any quality of my user experience, in this small academic endeavor. I am not feeling personally put off by the style of the writing in the FreeBSD handbook, as I understand that it is only one part of the ever evolving body of existing work in documentation about FreeBSD. Moreover, the article about PF makes all of an essential reference to the broader documentation. 

Personally, I've found it personally easier to make reference to the PDF edition of the FreeBSD handbook, juxtaposed to the web-based presentation of the HTML edition of the handbook. Moreover, I've put together a simple shell script to generate PDF editions of manual pages for prominent features of the PF services architecture in FreeBSD -- in that much, referring initially to  a single message of a FreeBSD mailing list, then adding some features for informative message output and error presentation, in something of a functional manner,

#!/bin/sh

THIS="$(basename $(readlink -f $0))"

msg() {
  echo "$THIS: $@"
}

ferr() { # fatal err
  msg $@ 1>&2
  exit 1
}

if [ -z "$1" ]; then
  ferr "no query specified"
fi

if [ -n "$2" ]
  then
    OUTF="$1.$2.pdf"
    QUERY="$2 $1"
    NAME="$1($2)"
  else
    OUTF="$1.pdf"
    QUERY="$1"
    NAME="$1(*)"
fi

ONOTIF="Generated file ${OUTF}"

msg "Querying for manual page ${NAME}"

MPATH="$(man -w ${QUERY} 2>/dev/null)"

if [ -n "$MPATH" ]; then
  zcat "${MPATH}" |
    groff -mandoc -T ps -dpaper=a4 -P-pa4 |
    ps2pdf - "${OUTF}" && echo "$ONOTIF"
else
  ferr "No manual page found: ${NAME}"
fi

Thus, I was able to easily generate PDF editions of manual pages, as for the following features specifically in regards to PF -- listed alphabetically:

• altq(4)
• authpf(8)
• ftp-proxy(8)
• pf(4)
• pf.conf(5)
• pf.os(5)
• pfctl(8)
• pflog(4)

Furthermore, for an informative purpose, I generated PDF editions of the manual pages icmp(4) and icmp6(4). I consider that I should wish to refer to those manual pages, at a future time, to further develop my understanding of the design and applications of the ICMP protocol and specific ICMP message types. It could perhaps be of some relevance with regards to zeroconf services, if not moreover CORBA, for local area network (LAN) architectures -- simply, "A guess," as it's not a thesis I've been able to develop to any further detail, at this time. ICMP perhaps may play a supporting role in a broader TCP/IP application services stack. Aside, I rather wish that the schooling I've received about Cisco tools would focus more substantially about the application layer in the OSI model, if not how any lower-level features of a TCP/IP stack may serve to support the application layer. Personally, I consider that it's a program rather entirely focused about Cisco's own proprietary presentation of the underlying technologies developed and implemented in Cisco IOS -- of some exclusively proprietary protocols, and some Internet Standards -- inasmuch as the course program provides any manner of coverage about, in itself. Though certainly, I'm quite impressed of a for-profit university's ability to, it quite seems, to comfortably reside in the hip pocket of a commercial hardware/software manufacturer, but I'm truly not of any impression as if it could whatsoever serve in the development of the state of the art, if all further networking services below the application layer would all be limited to applications and views developed in Cisco IOS. 

Personally, I'm moreover quite glad that I'd thought to look for works of vendors other than Cisco, at an early time during the for-profit university's effective programming. I consider that it's served to add a necessary grain of salt to my own studies under the same Cisco routers administration program. Not as if to insult the design of that program, I don't believe it's a program really developed for developing any real sense of proficiency, and neither for assisting in the development of the state of the art, truly, as much as it is a program developed for applications of some existing tooling. 

Thus, I am rather nonplussed that I've put my student financing to such a program. I try to not spend any long time dwelling on that matter, though -- that unhappy fact adding to my own struggles as a student. In regards to student financing, specifically, though I understand that it may be one of the easiest things of all, to remind of a sense of toxic pessimism about any situation of student loans, and there are some presidential administrations that would propose to altogether eliminate the capital nature of student financing -- so, of course, it would follow that we must vote for the same politicians, or there will never be a magic wand that would make student loans all "Go away" -- I don't believe any such issue is ever well suited to any real, practical ends. It may not be as well if a federal institution may wish to revise of any politics or, if ever, of any policies -- whether functional or wholly not -- as to how a capital income flow occurs, even insofar as how funding occurs to educational institutions, predicated on services rendered for students' academic study -- and that, moreover, that such federal leadership may seem as if to believe itself altogether insulated from the broader capital effects of such utterly naive policy. Perhaps it may at least serve to develop something of a sense of a litmus test for career socialists, in US federal offices. One might not have thought that the US federal government could have ever been designed or latterly redesigned as though to support such a manner of frivolous politics -- neither that it makes of any sustainable sense of capitalism, no matter how momentarily popular -- lastly, that a US President would ever seem like more of a social hacker than ever a governmental leader?

So, in such times, perhaps one endeavors to draw oneself more closely to one's own sense of principles. One might learn positively about something, therefore, and weather out the populist political snow storm, however long it may endure. Perhaps it may not be a permanent state of affairs, however, to be a capitalist veritably alone in among all of a radical, millenial, populist socialism, and all of its nearly mythical agendas. Neither do I imagine as though the proverbial pendulum would do well to swing to any manner of an extreme economic corporatism, either. Presently, I wish to consider that it has not been to any waste to have studied of the US history, moreover -- as previous to and during this time, when the US historical presence would be revised, if not entirely erased of the gross naivete of the nation's own national leaders, how much furthermore devolved to a point of meaninglessness, apparently for some kind of an imposing agenda, if only softly imposed of its own oligarchical apparatus, and for what beyond a quizzicalically empathic neediness, in a politics wholly out of step with the broader world, beyond the making of its own naive agendas? The US should as well divorce all of the Obama Administration. The short romance of the administration's boldly dumb socialism, however much it may entertain to the tune of any small business as usual, it is wholly unsustainable in the capital nation and the broader, real world. It's no good business, moreover, to follow the trail of repeated failures of the administration's real policy decisions, but -- even when and as it requires nearly a coroner's manner of view -- there is a kind of work to it, to discombobulate the lot of horribly naive media publications and observe the real, material effects of the administration's policy decisions, beyond the spin, to trace the developments of things back to their origins, so far as sense of reason permits, however unhappy the study. Thus, a sense of science may be retained even of the most unscientific administration to have graced the office with its charismatic chicanery, since the first administration of the Clintonium Estate.

Erstwhile, this article had been an article about a software system. The matter of a socialist administration's dryly charismatic but outrageously counterproductive mistakes -- as the author sees it, in wishing to be prepared for any further repercussions to come about, any further failures to become of the most frivolous and truly wasteful presidency to have occurred of any duration of human memory, in the US -- in considering moreover, the all out circus of agendas spun out from the same political parlor show, to the author's own simple sense of understanding, it serves to explain some of how a school comes about to merely program a student body for an only superficially informed application of some existing work, of a single vendors' products. It's altogether a trend of a nation dumbing itself down, moreover radicalizing itself towards a point of complete failure. There should be any better ends for a design of a trusted computing system, other than to "bunker up" for if that trend will be continued.

Thus, there might be something of a cultural side to a concept of nonrepudiattion -- perhaps not all of a hack-proof manner of a concept, itself, but at a point of simple intuition, if not for a stubborn analysis of real material flows and the information content of things, perhaps it serves to endure some of the obfuscations of any radical liberal snowstorm.

Returning to the matter of networking hardware: Though I've not found any completely indicative reference as to the origins of Juniper's Junos operating system, specifically, but having read of a rumor at least that Junos is derived of a BSD base system --- moreover, now understanding that the network routing appliances market is a market effectively shared at least by both of Cisco and Juniper -- then in assuming tha tJunos might have been derived of a FreeBSD base system, perhaps in some further experience with FreeBSD, one's knowledge gained might then be applicable to a support of Junos products. Perhaps Juniper may one day disclose the origins of of the Junos operating system, if any further support work might then become possible, moreover with a plain sense of resolve.

The author, presently endeavoring to match -- somehow -- the timbre of the times, would now wish to apologize about this cloudy manner of writing  It is not to be vague or confusing, this style of writing, rather it is to avoid putting out cookies for millenial opportunism, or any manner of plagiarism. Sure, it is much of an indirect style, and it may be difficult to parse, but perhaps this style, in as developed in a work of writing, it may permit none of a gamer's tactic for sharing of knowledge and information. This being not any manner of a technical reference work, the author considers oneself at liberty to be so seemingly obtuse. 

The author wishes to consider that those may all be positive qualities of any work of literature, anyway -- that the best writing is never easy to parse. 

In continuing at this plainly laborious endeavor of writing and writing not for any trivial sharing, the author etching out a work of writing, in sharing one's own opinions at this very moment of time -- not as if to program a readership to any single point of view -- there is a tangible thing in the design of the PF architecture. However, the author is rather worn out of dealing with the politics of the times.

Works Referenced

[Handbook] The FreeBSD Handbook