Towards Defining a Granite Express - A Microblog Messaging Framework for CORBA.

The following is the text of a comment I'd posted, this morning, via the Google+ social networking service. Proceeding from that text, I'll amend any further comments to the asterisk.

So, who wants to write a microblog API this morning? *

The grammar of that remark, I know it's all social networking-EN-ish.  Of course, one writes software, whether or not software a product that would provide API services.

I think I've found my first, so to speak, "Hot" business idea of this year -- but not as if borrowed from Status.net or Twitter insomuch as about messaging, simple messaging, irrespective of medium.

I've been commenting about amateur radio, recently. Personally, I'm a few license grades short of being able to communicate on HF-ALE networks, though I know they exist.

There are also bridge frameworks for networks. The electronics of an open source HF-ALE to C4FM/FDMA bridge would be tricky to implement, I'm quite sure -- the voice-mode aspect of the bridging would be the really tricky part, in anything short of a full dx/dy informed view, and then the rate of the data transfer in the digital-mode.

It's possible, hypothetically, for an institution to build a communication bridge to any place on or beyond earth. I don't think the UN has been chiefing that goal, however.

I think that's a pretty neat possibility, in terms of aid services.

As far as platform-agnostic object models, I don't know of any need for anyone else to reinvent CORBA, as it's been reinvented so many times already -- even in XPCOM, for instance -- but it's pretty square in its origins, however perhaps seemingly obscured with the long rhetoric of specifications documents.

So far as meta programming, hypothetically an inventor may  also develop a bridge for "webs" to radio media. However, there's a small concern of bandwidth, at that.  So, limiting it to a "LAN Webs" sense, and even on drawing the picture as to be broad enough to integrate software defined networking (SDN) services and a complete trust model for purposes of non-repudiation if not also for contextual authentication services, it's a concept that can scale, too.

So, as far as "Getting over the proprietary", and being however dishumored if there's a public school purporting to teach of siegecraft, online, but in regards to real communications in real support models, perhaps this might be my first formal smoke signal of an idea for communications support.  If there's any matter of existing work as I am formally unable to comment to, perhaps the reader may reconsider if one would wish to  "Sue me" over such? I can't even make reference to it, it's not "my own private property" to describe.

So far as my own small idea, today, about microblog-style messaging, it's an idea I would not so much as pretend to keep under lock and key, as it's an idea for support of communications. Of course, so far as I'm familiar with any kind of an existing work, I'm very cautious to avoid any reference to such. There's an orthogonal matter about an HBO series that I won't even comment to, completely, ,at that. Russia already has something similar, as I've already seen photos of.

Referencing the formal amateur radio aspects of the history of the Debian project[s], I think there's precedent that a radio communications community can find a place in computing,  even outside of any further specialization of CDMA, HSPA, or GSM networks, patents or no patents, and orthogonally, via 110% open design or perhaps rather naturally otherwise. There are only so many things anyone can make open at once, of anything that is their own to make open and that is not open already. Failing that, we have opportunists such as Julian Assange and all the Wikileaks fanbase -- is not? --  then Edward Snowden gets dragged in with it? Not me, not by any length of arc, not ever. Not even with a thousand foot pole would I ever touch WIkileaks, outside of one visit I've already sent word about, to whose attention it most certainly applied.

Towards broader views, certainly the sciences are most often describing of any number of open concerns, already. Personally, I consider that I can focus on the sciences, then,  so long as I'm not boxing my thinking up for a proprietary or otherwise closed design. There's an information theory I've read of. Communications -- as a meta-semantic concept -- it's almost beginning to make sense of me, from that point of view, regardless of the many specialized concepts developed to or about any of any various radio frequency bands, concepts expressed however independently of any concepts of other frequency bands.

There's a big electromagnetic spectrum that the science have described. Maybe it's as well if most discussions would avoid the shortest wavelengths, except by an approach described of calculus -- considering, any experiments at those wavelengths would most certainly require a corresponding layer of electromagnetic shielding, for overall safety all around. We don't all get to play Tesla ever day, we inventors, certainly.

Communications, even as at a layer of the most fundamental qualities of channel media -- I'm mostly concerned about the digital, though I understand there are countless applications also for analog communications, even in so far as to the voice modes of extensible multi-mode radio systems -- rationally, extensible so far as science may reasonably, rationally, and ethically allow, and in a legal sense, extensible if only so far as regulations allow, in any setting.

Link repeaters and link bridges, nothing proprietary in that much -- and not either, the essentially stable geometry of a geodesic concept in design.

I'd consider to offer a guarantee of this: If the EC ensures that an aid corridor will be developed, they can leave it to the all of us to make sure that the aid arrives safely at the end of its travels -- as always, nothing expressly proprietary in the basic sciences, and nothing too woefully  passive in all of aid for defenses. If however, I'm not personally on "That Go Team," I've studies to continue otherwise.

In short: CORBA IDL allows for a media-independent definition of message structures, such that may applied to transmit message data, such that may then be presented via a presentaitonal application, in a layout like of a microblog -- though all would be, fundamentally, it would be like a matter of text messaging of a kind. essentially in abstracting the microblog format used by Twitter even further than to abstract it as if exclusively onto HTTP.

CORBA ,inasmuch, allows for the message data and message presentation data to be carried independently. That's more or less what XML has been striving for, though XML protocols have been limited essentially to stream-oriented transports such as HTTP.

Removing XML from the discussion momentarily, and with CORBA in the discussion at least momentarily, the CDR encoding method applied in IIOP -- not only may it be applied in basic socket-oriented TCP/IP communications models without any additional application layers than for the essential data transport. Perhaps a CDR encoding  may also allow for a non-stream-oriented data encoding -- more fundamentally, a bus-oriented data encoding -- a "stream" perhaps in it being only a sequence of bits delivered within any specific I2C or SPI protocol.

It scales.

That it scales in a manner orthogonal to HTTP, what estate is there in the HTTP web as it is? Certainly, my small comment here -- it's not to insult any of the protocol doyens of the W3C, or their employers' marketing departments either.

HTTP itself is a message-oriented protocol. It uses a pretty rudimentary encoding syntax with the HTTP headers -- a syntax as also seen in SMTP and NNTP -- and then the HTTP message content, likewise similar to SMTP and NNTP. If computers are so fast and networking is so broadband for so many, so much that it might seem as if the cost of computing in negotiating data via HTTP would be negligible in most instances?

Keeping CORBA in the discussion, there are other methodologies still -- by far -- developed and -- by in large -- available for transmitting a message's data via a digital communication channel.


* That's an essential idea of a thing -- to develop a generic microblog API, in a short sense, and without any excessive effort as though for marketing  any manner of a microblog API, in itself. It's not a concept for a web-based microblog API, insomuch. Perhaps the only tricky thing will be to incorporate a CORBA SEC model for user authentication and user identity, in defining a service model for microblogging via CORBA. It's not such that I could say could be a "Throw away" design -- as that there are modes of messaging in which text messages are not throwaway objects, moreover that there are media apart to commercially exploited channels.

On Favoring the Democratic Nature of the BSD Licenses

I've begun writing an overview for a graph toolchain project that I've begun developing, as of this week, formally. It's a project, I think, that — in some sematic regards — extends back by at least a decade, was furthermore flummoxed of its humanitarian goals around the sensational hype about Edward Snowden's own actions in theft of raw data and intellectual property formerly of the NSA and affiliated instititions. The struggles one would would ever find in any single developer community, beside that — not to drag things out of proportion — perhaps one's own concerns, as such, may seem rather eclipsed of a significant number of broader concerns, at the data theft by Snowden. Perhaps one learns to not "Lead with empathy," not by any too much, in regards to development and implementation of computational systems?

Presently, I've arrived at writing a short overview about the license service design being developed in a graph toolchain project that I have begun developing, formally, in documentation and in a format of a UML model, this week  — having made reference, now, about CORBA licensing services and CORBA object lifecycle services moreover. Regardless of my own thoughts and feelings about any manner of applicable relevance of each set of such services, and their likely co-supportive relevance, I think that the licensing discussion may find a more semantically compelling focus around a question: How does any single licensing model reflect of a relation of creator's rights and, respectively, institutional rights? Is there, moreover, an opportunity to develop a licensing model as would singularly and legally derive an instution's own data rights as a function exclusively of creator's rights?

Taking the GPL as an example, it's my impression that the GPL is another license subsuming a creator's rights under an institution's rights. Even if it is not commercially affiliated, in any proprietary and exclusive regards, to any single corporate or governmental or otherwise non-profit institution, but simply in the process of subsuming rights to all of derived works, a GPL license thereby subsumes creators' rights.

Comparatively, a BSD 2 clause or 3 clause license makes not any manner of subsumption in regards to creators' rights.

Noting the time of the year, perhaps it may seem too convenient to observe that the BSD license, as a media rights license, is more like the governmental rights license of the US Constitution.

Thus, I'm favoring BSD in systems design, for networked, desktop, and mobile applications. Moreover, perhaps I might now be able to articulate: Why so.

The GPL effectively subsumes creators' rights of contributors, on the behalf of any project applying a GPL license. If it may be thought to ensure the integrity of any original project, as such, the choice of a contributor to contribute or not contribute, that much derives always, certainly to the individual contributor — assuming a contributor is not being coerced to contribute to a software project.

Comparatively, the BSD licenses present, in each, an indemnity clause, subsuming nothing of contributions.

In making what I consider is, firstly, a personally ethical comparison of the two respective license types, I consider that the BSD license firstly permits more flexibility for how software developers may devlop and apply any of, each, one's own contributions — the BSD licenses allowing for essentially any legal extension or application of software licensed under the BSD license.

Considering a BSD operating system, moreover, as it not presenting any ambiguity with regards to rights for licensing and linking to the kernel itself, I'm favoring FreeBSD moreso for its "Square" design, but the licensing concern makes a nice second to that, I think — in terms of a generic estimation of empathic/sympathetic value, if not moreover in terms of a functional relevance of things.

Perhaps a GPL license may see as if more sympathetically relevant, if the GPL may be presented as a "free/libre" license, however juxtaposed to any singular views of corporate policies of proprietary determinism, as some corporations have made, with regards to competitive ethics and software systems? Microsoft's old "Acquire and rebrand" policies, for instance — that echoes so far back as to the theft of CP/M itself. How may a software developer community ever defend its own productions against such acquisitions?

What, though, does the GPL ultimately defend, beyond the original works to which, each of a GPL license is applied? If it may be thought that a GPL presents a defense to any carelessly exploitaitive strategies in commercial acquisitions of software source code, but how may it defend from such? and what, moreover, may a GPL license prevent, in any terms of an otherwise socially accpetable commerce?

A GPL license might seem as though to make an institution of any single software project, in itself — but not altogether a benign institution, rather an instituion in which all rights for any derived, subsequent works all devolve to the original project applying the GPL. Is it so much a manner of a philosiohically democratic institution, any single institution effectively instated of any application of a GPL license to an ostensibly original work?

I propose: Concerning the GPL's approach to defense of ostensibly original works, it makes all of a naive defense, in a commercially and socially unnecessary way. It's as well, to me, if developers apply the GPL to each of their own original projects, however. Beyond any questions or views of binary linking,  the GPL effectively finds a boundary at the limits of any single network service.

The BSD licenses serve to permit for all of a value-oriented review of original works and original contributions. In a measure of relative numbers of freedoms, the BSD licenses are likewise more truly free in philosophical nature. Considering, as well, that the BSD licenses allow for any indefinite number of legal applications, how may I ethically choose to apply a GPL license to any ostensibly original work as I may ever develop of my own knowledge and experience? Would such decision ever devolve to my own small estimates about operating systems? Would I ever avoid applying a permissive BSD license, if to try as if to shun the BSD operating systems? Would that be an effective approach for software dvelopment, or for any manner of product marketing, or in any sense or manner of a philosophical focus in software and systems development? If one may wish to imagine a world of software products all susbsumed by a GPL license, perhaps it may then seem wise to shun any socially unfavorable license juxtaposed to the, so to speak, the miraculous GPL?

The BSD licenses effectively allow for contributors to retain, each, their own legal contributor's rights — each contributor being legally enabled to contribute any further developments and to distribute any derived works, legally so, with or without any broad social consultation about any logistics, philosophical goals, or material natures of the respective works. In a metaphoric sense, perhaps it's more to a hobbyist workman's model than any manner of a bazaar or a cathedral.

Considering a contrast of creator's rights and institutional rights — moreover, if any social and/or technical concerns are beginning to trend, with regards to models for digital rights management — of course, there are more license models under the sun. Not only are there each of the GPL and BSD software licenses, there are also the Creative Commons content licenses, and any discrete number of other licenses applied for licensing of software source code or binary application media — in terms of media and/or applications — and static media content. Personally, I've chose to focus about such contrasts of BSD licenses and GPL licenses as a set of contrasts not only of legal terms, moreover a contrast of philosophical goals, a contrast lastly having implications in regards to material and social means for software development and for developers' commerce.

So, it is not either as if to shun any products licensed under terms of a GPL that in a personal and a philosophical regards, I'm altogether favoring BSD.

Inasmuch as that two software services may interoperate across a network interface, irrespective of how, each, their software source code is licensed, the GPL might not be, itself, so virulent after all? If there may be a discussion of a broader concern with regards to data licensing, moreover, personally I foremost hope that the discussion will retain acknowledgement of content creators' rights, secondly of institutional rights as deriving from content creators' rights. Simply, without any one or more content creators, there would be no content for an institution to publish.

GraniteSchema - Updated from Introduction as Provided to Protege Project

The following text represents the current revision of a summary as I've presented to the Protege Project, this afternoon, when downloading the latest release of Protege 5.0.0 (beta 17). The text, as presented to the Protege Project, will have been the first initial summary published about the GraniteSchema project. This article now represents the present revision of that text, published here for sake of a simple, expedient access on the Web. The design of the GrantieSchema project is presently contained in a small number of paper sheets with hand-written ink -- the digitization of which, I will be managing with at least Protege, for definition of a graph in RDF OWL syntax, and Modelio or the Cubetto Toolset, for UML modeling and more generic conceptual modeling.

GraniteSchema represents a development of a concept of a UML profile and corresponding RDF classes/properties graph for modeling of logical and physical properties of small digital electrical systems. This project is begun about a concern with regards to differing versions of the Cyrptotronix CryptoCape, a 'Cape' type circuit board designed as an extension for BeagleBone single-board computers. Corresponding with the ad-hoc RDF graph and ad-hoc UML graphical syntax for  GraniteSchema, the project will develop a data model in the Common Lisp programming language, as well as a corresponding presentation model for each of web media and desktop/thin client display devices.

Although this project does not immediately aim for developing a platform-agnostic hardware and systems model of the original MIT CADR Lisp Machine, the CADR microcontroller, or the CADR operating system, it is a hope of the project's initial developer that the GraniteSchema project may eventually evolve as to effectively present such a complex systems design, if not furthermore to serve as an aid in any projects adopting MIT CADR for application on contemporary microcontroller architectures. and programmable logic circuits.

Presently, the project is being addressed to a semantically nearer goal of circuit modeling and simulation, with regards to the BeagleBone Black single board computer platform, and the CryptoCape, an expansion board for the BeagleBone Black. This project may endeavor to develop a small number of orthogonal models, in furthermore developing any small number of project support services, such as with regards to licensing of source files and literal content files -- focusing on license content, as well as processes of license access and license adoption.

In a later revision, the project may endeavor to develop a single generic model for electronic comunication systems, focusing on Ethernet networking, I2C and SPI for  modular communications within individual electrical systems, and systems for software defined radio.

This project will endeavor to present a comprehensive -- albeit, in many regards, certainly an ad hoc model -- for each manner of view to which the project may develop any singular extension. Presently, the GraniteSchema project will endeavor to develop a view of physical connectivity and logical containment for individual circuit boards and expansion boards, focusing on the CircuitCo BeagleBone Black and the Cryptonix CryptoCape.

Towards an Emergent Concept of Task Scheduling and Ontology

After reading an article, this morning, in the Taskwarrior documentation[1] — specifically, an article about the Taskwarrior JSON Format[2] — I thought it would be well to take pause and develop an orthogonal concept.

... an orthogonal reference to the iCalendar data record format[3], as concerning syntaxes of duration strings, in programmatic data records for regularly/periodically occurring event data expressed in iCalendar formats[4]  — to denote a thesis statement, in albeit an abstract sense, as regarding:  Internal representations of data record values, within programmed data systems.

Some Thoughts — Initial Thesis Arc

• Data registers — historically, cf. MIT CADR and the original Motorola microcontrollers
• Data record formats — cf. Common Lisp type system, and C type types system, primarily to a juxtaposition of structure data types (i.e CLtL2/CLOS/MOP structure-class implementation[s] and C 'struct')
• Data interpreters and unambiguous grammars (cf… awk? Mathematics of finite state machines, graph theory, abstract principles; a leap to BNF, parser generation, and parser applications; Common Lisp readtable, CLtL2 standard syntax; read/eval/print loop; case study, de.set.atn and de.setf.xml)
• Sidebar: Code alignment, in Common Lisp programs. cl-json
• The shiny thesis punch-line — albeit, arriving too late in the dissertation
• The pragmatic outro — tip of a hat to the development cloud?? 

Some Thoughts — Secondary Thesis Arc

• Measurement Theory
• Units of Quantity, Units of Measurement, Mathematical Interpreters, floating-point errors, and the Igneous-Math codebase
• Duration of Time as a measurable quantity
• Generic encoding for duration of time, in a format of a constant value as may be added or removed to a numeric time coordinate value encoded as Common Lisp universal time
• Juxtaposition: UNIX Epoch Time

Immediate Considerations:

• Installing Taskwarrior Server on FreeBSD
• It uses JSON, therefore probably needs an HTTP sever
• NGinx on FreeBSD
• Chroot virtual jails in FreeBSD
• Creating a virtual jail
• Virtual networking for virtual jails
• Load balancing for virtual jails, using PF
• HTTP auth methods may include: Kerberos (SPNEGO?). 
• Client support TBD
• Configuration
• Alternative: LAN/SDN/VPS config
• Denoted in the previous
• Alternative: Third Party Hosted config
• Shout out to a company with support staff for the hosted config
• Installing Taskwarrior client applications
• ... Android client  
• … client … PyGTK [FreeBSD; Debian 8; GTK on MSFT8.1?]
• … client … ncurses [FreeBSD; Cygwin; Debian 8]
• And why not right now: "Because"
1. Too immediate
2. Too many opportunists
3. Free Software Estate / Free Beer Elite ?
4. No Solution
• Chalking-Up Point and Mark
• What this began as; A search for a simple task management platform, such as might be available on the FreeBSD operating system, and as might be available without it requiring that an enterprise grade cafeteria or stew kitchen -- complimentary with kitchen sink -- be installed on a LAN server, viz a viz. brand Enterprise(TM) portal applications
• What this became, at this article: An initial design sketch -- the author fails to note clearly -- for a definition of data records as may be able to read Taskwarrior protocol messages (JSON structures) in Common Lisp
• What this will not be: 
• Will not be: A sly effort for co-opting Taskwarrior. It's not a business hacking project, this, it's a "success," in and by a technical extension project.
• Will not be: A leverage for making an academic career, "Finally and at last!" within a really terribly rough time, academically, with some "Universities" -- mitigated only by the selection of an online "School", for all the costs of it however. 
• Will not be: A pointed divergence to an entirely orthogonal design
• Will not be: Rise of the Lords of Lambda Dance, The Great and Final Emergence of Lisp Politics, the Cloned Wars, or of The OS named, Thing That Should Not Be(TM)
• But might be: A carrier for. finally and this day, a shout/out for a Metallica song, noted in the previous itemized list item. It's a darker sounding kind of hard rocking song by Metallica(TM)
• What this is, presently: This is a 'blog article. "Ciao!"
• Ed. note: The "Emergent" keyword in the title, that kinda throws it.
• There was an emergent concept - towards a view about moreso a data model for data records in a task scheduling  application, namely Taskwarrior -- albeit, initially, to no single application, in Common Lisp, therefore a data model without communications encoder, channel, decoder or receiver models, abstractly -- but including a concept: That Common Lisp may be applied in this system. It's even listed in the FreeBSD handbook, albeit not a compiler LoL.
• Between the first and second edits of this article, the concept of an emergent concept -- as was being addressed of this article -- had appeared as though to cease to emerge, as a concept.
• Presently, to a matter of ambiguity: The phrase, "Towards an Emergent Fum" might seem as if to suggest as though there was not already an existing Fum in the known universe of discourse -- a grammatical irony, certainly, in that with the instance of the original title of this article, the original title could be kerned as so, and it be more to the original point: Towards [SP] an emergent concept [SP] of task scheduling [ELLIPSIS] s/o to the Enterprise Common Lisp wizards beyond the green curtain (SNARK)
• Thus, the initial title of the article -- in all the expedience of the article's initial authorship -- the title, "Towards an Emergent Concept of Task Scheduling", did not serve denote the full concept that the author had wished to develop of the article. 
• To the author's own short recollection, this article was begun simply at the nearest concept that the author wished to develop. It was, in fact, an article begun in the Blogaway app on an Android thin client computer. 
• Not as if to shunt a development community of either empathy or culture -- as with regards to not presently developing Common Lisp altogether, if one is not, with no further discussion about the sustainability of purely academic projects -- it was rather a simple concept of a data structure, at the onset of this article -- focusing, albeit in short note at the time, about the syntax of a duration data type defined in iCalendar. 
• Not as though to indulge here on a Sunday afternoon, perhaps this lengthy discussion may now serve to bring the article, succinctly enough, back around towards its, albeit poorly stated point
• In its second major revision, this article is now titled as so: Towards an Emergent Concept of Task Scheduling and Ontology
• The phrase, "And Ontology," perhaps may serve to add a unique sense of emphasis to the title, as towards a broadening view of an applicability of ontology in data systems
• However, in such proximity to a discussion about Common Lisp, perhaps the phrase may seem as if to add a suggestion as though it was to become a thesis derailed in whatsoever, derailed of a concept of either Passive A.I or the mythical Non-Passive A.I -- both being concepts that the author prefers to simply not create stories of.
• So, the phrase "And Ontology" may need a further lexical qualification
• This article will presently diverge to a secondary thesis, in introducing a concept of ontology
• What does the author know about ontology? (ad hoc syntax)
• Knowledge expression in a tuple format: 
• Subject_1, for instance, an RDF resource denoting a lunar location, "Dark side of the moon"
• Predicate_1, for instance, and RDF property denoting a relation such as "Is the location of"
• Object_1, for instance, an RDF resource denoting a philosophical enigma, "Narrator of that song by Pink Floyd"
• Predicate_2, an RDF property, "referenced from"
• Object_2, e.g. "That one song by the band, Pink Floyd"
• We may then express the relation in the song, succinctly
• M = {Subject_1, Predicate_1, Object_1}
• Furthermore, we may make note of the source of the reference, given that available data
• N = {M, Predicate_2, Object_2} 
• Thus, object N expresses a reification of an existing tuple, namely in a relation of tuple as Subject
• The applicable role of reification as a method for bibliographical citation in ontological data structures -- is that, as yet, undiscovered concept, might it be, in so much reflection of all the Huge Data? 
• Given the "Given axioms" as presented:
• Anyone whom may legally access both of objects N and M -- as data objects, with no present review of objects denoted by the data -- essentially anyone then should be able to review the definition of M for its reference denoted in N, and likewise to review object N for the statement that it is drawn to, in the bibliographical reference, namely object M
• Thus; This describes a method for making albeit a non-narrative data reference with a peer-reviewable reification format, in a manner of a bibliography
• How could this be relevant? In reviewing details of a crisis, it avoids all of a coroner's view of the data.
• Inasmuch as it being a non-narrative statement -- not an article, not a report, not a book in itself -- the author sincerely does not want to decompose all of language into tuples. If it seems that there are methods for such deomposition, certainly it may serve as to comment to the essentially communicative nature of language. Presently, author is presently unwilling to decompose -- if any arbitrary regards -- to arbitrarily decompose language into any smaller expressions than of the individual list items of an individual itemized list, in the hope that it may serve as a reading aid to the inevitably busy reader whom might otherwise entirely dismiss this article from the reader's own attention, as with a remark, "TL;DR". The irony.
• Of course, in developing this article now as albeit a lengthy itemized list, it might seem to approach the limits of the itemized list as a format for human communication.
• Furthermore, ontologies may be applied in study of non-crisis-oriented resources
• Literary applications
• Applications in archaeology
• Applications in aiding with consumer selection of mass-produced commercial goods
• Applications in aiding any number of  service help desk personnel for selection of knowledge base articles, for resolution of consumers' personal if not primarily technical concerns -- even if the knowledge base itself is as wide as the entire The Internet, at any single instance of time -- though likewise preserving something with regards to privacy in any single consumer-support relation, as per any support personnel's own sense of professionalism, if not moreover the structure of a support system in itself.
• ...likely ever in assisting to ensure that any crisis N will not emerge, even if a crisis M may be already underway.
• Perhaps, ontologies may be applied even in a study of an abstract concept of crisis, in itself
• It might seem as though to entail a sort of coroner's view, however
• Thus, objectivity.
• ...and moving on, literally?
• Shout-out to the coal miners and metallurgists of Donbass.

Footnotes

[1] http://taskwarrior.org/docs/
[2] http://taskwarrior.org/docs/design/task.html
[3] http://tools.ietf.org/html/rfc5545

[4] http://tools.ietf.org/html/rfc5545#section-3.3.6

On locating Taskwarrior - An Overview of Projects

Earlier this morning — here on the very day after Independence Day, 2015 — I had decided to run a web search as to inquire, in a sense, about the availability of web resources concerning any single concept of a supoort for project management, on the FreeBSD operating system. In addition to a short page about project management within the FreeBSD Project, itself — with an observation, as by contrast, that one may only hope as though there could be such any single page published, as in any ways analogously, of the entire Debian project, today[1] — I also found a short index of projects hosted at SourceForge.net[2]. I'm writing this article with the Blogaway app, this morning — I will provide a note to any corresponding web resource locators, in footnote form, along with any prosaic footnotes. As ever, #GIYF.

What I have found — as resources corresponding with this morning's web search — firstly, there is the Taskwarrior project[3], as hosted at SourceForge.net, and there is the corresponding Taskwarrior web site[4]. (Presently, I'll continue this article with the Blogger web client.)

Towards a Comment in Contextual Computing - FreeBSD on LAN

Personally, as immediately previous to this morning's web resource search, I have been developing a small set of notes, around a study of the PF firewall -- as was forked from its original development in OpenBSD, then introduced into the FreeBSD base system.[5] In a manner chronologically previous to that study, I'd developed an albeit ad hoc and nearly arbitrary configuration for the IPFW firewall[6], in configuring a simple network address translation service for a LAN gateway.

As something of an orthogonal comment, perhaps towards a sense of context: The single laptop-based server now providing the LAN gateway, in its FreeBSD root (UFS) and swap partitions, it comprises what's been my own first installation of FreeBSD, in a "Bare metal" regards. Previous to the installation to the PC, I'd installed FreeBSD into a VirtualBox guest system, using the FreeBSD virtual machine VMDK image .The VirutalBox Guest system, however, howas running on a proprietary desktop operating system. Though I had thought that it could make for something of a comfortable desktop arrangement, but I thought I would be more comfortable with a "Bare metal" installation.

Following to the installation of FreeBSD (amd64) in developing a LAN gateway appliance for my small GraniteLAN, I've now installed FreeBSD on the laptop where the other proprietary operating system is installed. That laptop, now, is also booted continuously to FreeBSD. It's tasked out, on my LAN, as it providing a small set of filesystem services and software compilation services for the LAN. Though, candidly, I've yet to configure a complete package repository of on that laptop, but I'm certain that such a service would correspond well to the package build automation service.  In the latter regards, I've begun to work out something for a configuration in applying the FreeBSD Poudriere tool, for building sets of packages as corresponding to individual host profiles -- building thee same, all with /etc/make.conf configured as follows, namely in regards for a machine-specific compiler optimization and (viz a viz -j4) parallel build configuration:

## cf. /usr/share/examples/etc/make.conf

CPUTYPE?=core2
# See also: /usr/src/share/mk/bsd.cpu.mk

#BDECFLAGS=     -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \
#               -Wcast-qual -Wchar-subscripts -Winline \
#               -Wmissing-prototypes -Wnested-externs -Wpointer-arith \
#               -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings

CFLAGS+=        -msse3
CXXFLAGS+=      -msse3

COPTFLAGS?= -O -pipe -j4

Essentially, that serves in creating a certain species of platform definition, namely in creating a set of packages compiled for amd64 architectures, core2 CPU type, moreover appyling those specific compiler optimizations. Though it was a rather functionally easy thing, to begin to develop that configuration, but I have not wanted to rush around to the point of applying it together with Poudriere and HTTP, even on my own small LAN. My being of an impression that there must certainly be some things that I've yet to completely work out, as with regards to such a framework, in its present configuration-- focusing about the package builder and hypothetical package distribution services, namely -- I've not wanted to get the cart situated before the horse, in those services. Perhaps the matter of it defining a species of architecture may be the next thing that I may take to consideration, at that -- towards then defining a second species of architecture for package-building with a cross-compilers configuration and package distribution on the same LAN, namely for an armv6/granite architecture. The "Granite" tag -- essentially, synonymous with "Prototype", in that application -- it would denote that it is a local architectural configuration for GraniteNet,

So, but previous to any further development for a package build/distribution service, I've wanted to adapt the GraniteLAN gateway appliance to use PF instead of IPFW. Not as though to make any sort of a negative impression about IPFW, it was simply a first choice for the LAN gateway appliance. At the time of my having just recently installed FreeBSD to the LAN gateway, I wasn't altogether certain of whether to apply PF, IPFW, or IPF for the initial network address translation services for the gateway.  As I recall, the IPFW documentation had simply seemed a little easier for me to understand, at the time. Now after having found some repeated concerns with regards to FTP PASV transfers across the LAN gateway, in its present IPFW  configuration -- even inasmuch as to retrieve, simply, a PDF edition of the FreeBSD handbook -- I've begun to read the further documentation about PF,

As corresponding to that matter of a simple study, this week -- and and not as though to crowd out any manner of attention from any of the existing projects for firewall appliance operating systems deriving of FreeBSD, such as OPNsense and, comparatively, pfSense -- I'm now of an impression, candidly, that PF may be one of the most advanced firewall systems available for a free/open source operating system. After reading the pf.conf manual page[7] with it converted into a PDF format for PDF annotation, furthermore in keeping abreast of my own observations, with a single note in my Evenote notes, I've begun to develop a small number of firewall appliance profiles, as in bouncing some ideas off of the pf.conf documentation, and in consideration of my own present range of studies -- such as, towards a concept of applying pf.conf for a hospitality network firewall, and towards applying pf.conf in a firewall for a WAN-to-Hughesnet gateway correspondingly.  The idea, to my thinking, is to be able to support the convenience of wireless access points, at rural recreational destinations -- ideally, as in coordinating with hospitality service providers, if having previously arrived to any opportune arrangements with hardware and network service providers and distributors, in endeavoring to make it a commercial opportunity, realized with steady management, -- as rather than it becoming any kind of a a radically emergent manner of thing, as if removed from management at any single hospitality location. I mean, it's a business idea, not a "Flash mob" thing.

It will, of course, will need be made with some careful coordination over time, if it may ever become a well managed business idea. It being nothing of any proprietary manner of design, moreover, it's just as well to me, to share these comments about that -- one of my own business ideas, as such -- here in my own tech notes web log, online.

In regards to a quality of service, in a commercial sense: Personally, I've seen how very harsh the comments are, from some many of the critics of free Android applications, in their comments about Android applications at Google Play. I think, it kind of presents a sort of a an immediate barrier, moreover, as with regards to Android application development altogether. Personally, there is not a chance on or beyond earth that I would ever be willing to develop any manner of a free application if it could be in any ways as if to flatter such an ungrateful lot of users. I'm not even of an idea to develop any sort of a for-fee application, to such a community of fundamentally immature, essentially mean Android users, if it may in any ways entail that I should have to encounter such a lot of impulsive, if not abusive rubbish in any manner of providing customer support.  Perhaps it may have something to do with how convenient the Google web experience is, to such critics?

I am not of an impression as if it ruins all of the Google Android platform, though I am quite sure it serves to ask for some further consideration -- such as to how one may endeavor to provide any manner of a professional user support, for any professional manner of user community. Certainly, I hope Google will continue to "Leave the door open to us," to choose among any number of available options in such regards, for those of "us" who would be Android application developers -- assuming that I would make a commitment, of my own  voluntary consideration, to develop applications on the Android platform. Of course, there's also Firefox OS, from the Mozilla foundation -- Linux and Gecko, essentially -- and there's Tizen, from Samsung, essentially Linux and the EFL toolkit from the Enlightenment project -- Tizen being, ostensibly, something of a "Clone" of Android, or so it's been said, if it is not instead a clone of Maemo, or any number of other mobile operating systems built on a Linux kernel. Secondly, then, there's the FreeBSD kernel, the BeagleBone platform, and some number of concepts in "mobile to mobile" i.e "M2M" computing.  Certainly, it may need something of more of a a professional style -- by far, more professional than what I may ever estimate of so much of the Android userbase, now -- if it could be a platform.

So, then, there's the matter of task management -- no small sidebar to nod a tip of the hat for all the "Apple-ness" of the Apple computing company.


TaskWarrior and the Shell Terminal Portal

In trying to develop a simple manner of a back to basics approach to business and broader commerce, moreover in a view as with regards to academia and the fundamental mathematics and sciences of things, and though I've been struggling personally to understand how that could ever be factored into any sort of a cultural climate, in California specifically -- and it be all of nationally legal, economically sustainable, personally ethical, and socially practical, to all of my best abilities to reasonably estimate of such qualities of a business endeavor and furthermore, qualities of any single, regional social climate in California --  firstly, I've been of an impression that I should plan to move to another state. I cannot begin to estimate, in full, what anyone may consider to be socially practical in California, where all I'm seeing is, on one hand, a millenial radicalism and secondly, a sort of managed statism, such that it resembles -- to my best ability to estimate and to comment, succinctly -- a liberal nanny state, such that moreover I cannot imagine the state's contemporary society be actually sustainable, beyond the state's own apparent codependency on so many existing modes of corporate industry -- and certainly, to much of an albeit relatively small range of contemporary, if not wholly commercialized entertainment. If I had ever thought that was "All the world," but after my experiences in a few years enlisted in the US Army, but then on moving back to California, I know it is by no means "All the world."

To my point of view, California is developing much of a grossly immature society -- a society becoming more markedly immature, every year -- a state essentially, then, becoming repulsive to any further, genuine sense of innovation. So, to my point of view, it is by no means an economically sustainable society -- perhaps, much to a further sense of irony, for how awfully narcissistic the people are. That I do know of a broader world, now, it's not such that I may ever voluntarily forget.

So, but in my little niche in all of this state's broad geological diversity and ironic commercial hegemony, I've been trying to develop an idea for how to put together some simple software tools to make anything manageable original, sustainable, and commercially productive, beside my own senses of interest about archaeology, ecological conservation, tourism, and typically low-horsepower, small-footprint recreation in the outdoors. Those interests, I consider, those interests can travel with me.

Of course, there's also my ongoing study about social developments in the Middle East regions effectively overlayed by Kurdistan, and the level of support heretofore provided to Kurdistan, in the Kurdish engagement to the conflict against the singular brand of militant extremism waving the false flag so know of ISIS -- lately, also the Taliban militants' attacks as conducted against the Afghan state -- lastly, then, so much grossly frivolous misguidance from President Obama and the broader The Administration(TM).

This morning, I had simply thought to search for a matter about task management, in a sense of project management, for an idea as with regards to managing a local area network. I would not wish to let that be sensationalized, however, of my own views with regards to executive leadership and/or gross federal executive mismanagement. As to my own views of all of these topics, of course it all may serve to shape my own sense of context about even this relatively small endeavor of having searched for a task management application for a local area network.

In another sense, if there is a presidential administration so endeavoring to make a federal fire sale out of a federal government, perhaps this small endeavor might seem too timely, and though much I am a fan of Bruce Willis' own work in the performing arts -- likewise, Steve Buscemi -- but this is by no means to emulate a Die Hard film. Not is it either as though to emulate any films depicting of any single, human guided landings on any asteroids, comets, or minor planets. If there's anything it must be said to emulate, in science fiction, I would rather wish to draw a metaphor of The Heritage Universe, by Charles Sheffield. That story begins on a planet named Opal. The author would not wish to spoil the reader's view of such a story, however, if it may spoil as to comment as with regards to any manner of a sense of elasticity in any single theory or concept of a time/space continuum.

This article, I hope, does it got all the things, then? There's even a passing reference to the Deep Imapct and Rosetta/Philae programs, with a nod to a recent speech by Buzz Alrdin, for a sense of semantic closure in regards to space exploration process in crewed and uncrewed spaceflight.

So, this morning I'd found a task management application for servers, Taskwarrior. listed among some other other task management, if not broader project management projects hosted by SourceForge.net[2]. On noticing some short documentation about structures of data record sets in TaskWarrior[8] -- and, in a breadcrumbs sense, I had been reading about OpenSLP, then DNSCurve, shortly previous to the search -- I thought, essentially: That I've finally found a task management application, such that might integrate well with my own perosnal range of expertise, experiences, and resources, at this time.

Proceeding from that observation, I began to sketch up an idea with regards to integrating Taskwarrior and Modeshape JCR services -- I had blogged about that, this morning, in my Google+ social networking blog[9] -- as well as observing that there is an NCurses TTY/terminal shell client for Taskwarrior, tasknc, listed at the Taskwarrior tools page[10]. Considering how much I've been working with shell terminal interfaces in managing my LAN's gateway and build host appliances, moreover considering the dolefully corporate managed interface of Cisco IOS -- such that I am familiar with, to an extent -- and although I cannot even imagine to install Taskwarrior on a Cisco networking appliance, I think I may now denote what impresses me the most about Taskwarrior: That it can serve to both prettify and organize the shell environment -- moreover, effectively including a shell environment in a broader hypothetical management information system (MIS) network applying Taskwarrior for task management -- without it drawing all of Emacs into any manner of a console located however semantically approximate to any manner of a superuser access, moreover.

What thing might it resemble, whether or not unlike the Little Shop of Horrors, if Emacs was run as Root, on a network routing server? Certainly, it may be, "Not a Great Idea(TM)," in some short terms. One might wish to expect that if a terminal-mode application may be run on a network routing server, that it would not ever load the server's microcontroller, however it may be applied as to correspond to data on the server.

Of course -- as towards a concept of furthermore developing a concept of applying Taskwarrior as a support tool, in as may be applied in a development of a server management architecture -- one could run Taskwarrior in a terminal beside any terminal connected to any manner of a network routing appliance. However, with Taskwarrior installed directly on the network routing appliance, it would then be able to access resources of the network routing appliance, directly, such as to provide any manner of task content data or task verification data, in any data records as may be developed in the progress of a task.

So, broadly, I think that one of the nicest features of Taskwarrior is that it has a clearly non-imposing design, that the Taskwarrior API can be applied in even a light-duty terminal environment. In that itts design might require only a a small footprint for a task-management protocol and application, it may not be any sort of any too resource-intensive task management service to apply. It might integrate well with other applications, too -- perhaps, in a sense, much analogous to a classic text stream piping methodology, for processing textual data with shell terminal applications in a UNIX environment.

Likewise, perhaps it may not essentially need any manner of a proprietary focus, to carry its architecture by -- comparatively, not requiring all of an enterprise proprietary J2EE services stack for its implementation. Of course, the JCR integration would be another matter, at that. Towards integrating Taskwarrior withing a documentary content management service, however, perhaps it may be worth the effort.

Towards integrating Taskwarrior with a desktop development environment, of course an Emacs Lisp interface may be easily developed for Taskwarrior -- towards something of an IDE-like integration, moreover then in an application of Emacs Lisp, as a relatively light-duty programming language -- however in parallel to the the NCurses client, considering Emacs' dual-mode applicability for desktop windowing systems and terminals.


Footnotes

[1] In FreeBSD, there are ports, packages and package repositories, and the FreeBSD base system — juxtaposed to package maintenance, packages and package repositories, and perhaps, the Debian installer, if the latter may be denoted as it being in any ways analogous to a base system, in Debian. The package maintenance concern, in FreeBSD, as it deriving of ports — perhaps as may be contrasted,  in an  immediate and perhaps naive sense, contrasted to Debian source packages —  a concept, rather, of any single manner of package management with a FreeBSD installation, if any single concept may be developed, as such, perhaps it may be developed as with a sense of supporting a manner of decentralized software distribution. Perhaps one may consider whether it could be sufficient, to simply configure and batch-build a set of FreeBSD ports with the FreeBSD Poudiere tool, then to host the resulting packages in an organization-local softwate package repository. Though it might suffice, in some terms of convenience, however it may not — in itself — obviate a concern for user support, within same organization.
[2] http://sourceforge.net/directory/business-enterprise/project-management/os%3Awindows/os%3Afreebsd/
[3] http://sourceforge.net/projects/taskwarrior/
[4] http://taskwarrior.org/

[5] https://www.freebsd.org/doc/handbook/firewalls-pf.html
[6] https://www.freebsd.org/doc/handbook/firewalls-ipfw.html
[7] pf.conf(5)
[8] http://taskwarrior.org/docs/dom.html
[9] https://plus.google.com/110843395386227107116/posts/coUbJnWWmT7 in HTTP[S] URL sytnax
[10] http://taskwarrior.org/tools/

All the little thing hacks - Cygwin + msysGit integration and ssh-pageant for Cygwin tools availability and Git SSH auth

Assuming of the following preconditions:

• Microsoft Windows is installed on a PC
• msysGit is installed with Microsoft Windows
• Cygwin is installed with Microsoft Windows
• User's $HOME is configured as to be uniform across the msysGit BASH and Cygwin BASH terminals
• PuTTY's Pageant tool is installed and initialized in the user's desktop environment
• The Cygwin ssh-pageant package is installed

...then the following SH snippet may be added to a users's ~/.bashrc file, to an effect:

• That Git will then be able to use ssh-pageant when authenticating to remote Git repositories
• That the user will furthermore be able to access the more of tools installed with Cygwin

Snippet follows

# n.b `uname -o` may not be available in MINGW32_NT-6.2
case $(uname -a) in
    ## Define a CYGHOME pathname in terminal-local pathname syntax

    MINGW*)
        
        ## e.g msysGit BASH terminal
        ##
        ## add Cygwin path, for convenience
        ##
        ## Notes:
        ##
        ## * The MINGW32_NT terminal provdies UNIX-like patnames for
        ##   Microsoft Windows drive volumes in a way divergent from
        ##   Cygwin's own volume=>pathname mapping.
        ##
        ## * If git is also installed with Cygwin, then it may result
        ##   in unexpected behaviors to add Cygwin to the PATH for
        ##   msyGit. Thus, this script will not modify $PATH if Git is
        ##   known to be installed under Cygwin
        ##
        ## * If Cygwin is not known to be installed, CYGHOME will not
        ##   be defined
        
        if [ -d "/C/cygwin64" ]
          then CYGHOME="/C/cygwin64"
        elif [ -d "/C/cygwin" ]
          then CYGHOME="/C/cygwin"
        else unset CYGHOME
        fi
        
        if [ -n "$CYGHOME" -a ! -x "$CYGHOME/bin/git.exe" ]; then
            PATH="${PATH+$PATH:}$CYGHOME/bin"
            export CYGHOME PATH
        fi
             
        ;;
    
    CYGWIN*)
        export CYGHOME="/"
        ;;
esac

eval $(ssh-pageant)

The previous SH snippet is provided by its author, Sean Champ, 4 July 2015, under a public domain #YMMV license.

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