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
