Customer Support at Five Minutes to Mark Zero

Customer support services – there's a certain topic for the modern Web? With no lengthy thesis about business process management, stakeholder analysis, or theories of culture, or of community and narratives, customer support is a topic that the author of this article is in some ways well familiar with. So far as the topic ever finds a context in free/open source software (FOSS) systems, maybe it could be to a broad definition of a sense of customership, with no too exacting definition of a concept of commercial services.

The Debian concept of a social contract, as sometimes denoted with regards to a concept of FOSS systems development, it may seem to represent all of a constructive, if not novel, if not in all ways a naively idealistic concept with regards to social ethics in practices of software and systems engineering. Whether or not it may seem to represent any sole, guiding principle in the work of developing FOSS systems,  the Debian Social Contract may at least serve to represent a great, higher ideal, towards consideration of a social aspect of software and systems deveolopment – a sense of principle, towards a social regards in software and systems engineering  – without specific delineation of a sense of institutions, in wordly material endeavor. In the contemporary, multiply connected universe, it may seem to be a concept in some ways strained, however, strained of so many narrowly globalist, nationalist, and more narrowly exclusive – if not naively exclusive, to denote such concepts in a manner of far understatement – irrationally exclusive narratives, such that become to no apparent gain in so many agendas' real world representations – no gain anywhere and much of destruction, of the apparently non-sane objectives of a radically populist riot state – the near ends of things, as demonstrated in Ukraine and elsewhere. What social contract may hold, of such a world?

How can anyone propose to develop software, in such a world, if the global customership may include representatives of an army of murderous, radical thugs? The coy – may one call it coy? The coy manipulation of news as if to suit a narrow, naive, if not fundamentally anti-humane narrative – as represented in Ukraine, and elswehere, sometimes even to a point where those whom may seem to imagine themselves controlling the chaos would literally boast of their delusional affronts to the very nature of humanity – how is that even a trend, of any social climate? and yet, it has occurred in some of the very real world.

There is certainly a lot of human nature such that any single social contract may not immediately serve to address, of any human endeavor. In that a social contract may serve as to establish any sense of a guiding principle, vocationally – but not to be preoccupied of worldly vocations. The author of this article very well wishes that everyone may enjoy a solitude like of Thoreau's reflections at Walden Pond – even for a short time in life, to reflect apart to material vocations – but how may a scholar maintain his hut, if the scholar would be forever about to make an idle thesis of an idle place?

Apart to any radical social environments online or in the broader material world, what manner of a reflection may be found of broader life? What consideration developed, thence, of any material nature undespoiled as of the material debauchery so deeply criticized by Thoreau? and on return to a radically materialistic community, what to? To depart, thence to make a candid appraisal of radical materialism, may it be? What some social climates resemble, in the world – hell is a word for it. Albeit, it is a word denoting a concept not introduced of any single social contract. An analysis of hell, as a concept – but such a vocation has already been approached by Dante and Virgil. Notably, Dante's own travels had not ended at Inferno, that Dante literally went through hell for Beatrice.

So, why does anyone try to make any kind of an ad hominem bias about software? An anthropologist's study of a sense of cultutural identity could be apropos, if there were not so many innately fratricidal cultural identities afoot in the world. The toxic agendas of an innately fratricidal radicalism – how does anyone set about to offer any of a sense of incentive to such a thing? If there is no incentive ever so much as imagined of it, then how does it continue? May there may be some people fundamentally aloof to the aims of a radical community? How, then, to mend hell on earth?

It might not be in any single social contract, not even in the smallest of fine print.

So, there being possibly more to life than as any single social or vocational contract may encompass, of itself, there is probably a consistent value of literacy – though it have the scholar situated squarely in hell, apace, if to follow the path of Dante Aligheri. The radical Inferno, the enterprise Purgatorio – and is there not any astronomical Paradisio, in this one scholar's poor knockoff of the Divine Comedy?

What social contract is there, and what society, if the world is all a mass of debauched individualism?

What customership, if we are all set about to prove a fallacy of social "Darwinism"?

What institutions, and what a profound aloofness of what self-serving potentates of merely political festooning, in any place much needing of a rational and authentically conscientious leadership?

What has the world brought itself to, in these years? What fortune, to be alive in such a time? And how much of the world forever glib, aloof to all the furthest immoral depths to which any society in the contemporary world has yet plunged itself? Would one ask such a question, though, and the question be answered by all the more of a news of a cruel debauchery in the world?

That, and an odd theme of socialism's implicit dysfunction – there may be a guiding light that occurs, even in a social Purgatory, if not moreover in an intellectual hell of a world gone squarely off of any natural, rotational axis, if not in a world seeming to be actively trying to herald a global Armageddon?

For all the news that a commercial journalism has not reported of – again, this topic is not addressed of a social contract.

There may be limits to the validity of a social contract, as much as there are limits to the literal scope of a social contract. There may be limits to a sense of imagination, moreover, none too well aided of a trauma reporting – and the human imagination stretched to a point of breaking, if anyone tries to leverage a propaganda of an atrocity made in real human actions, in the world.

For all the real traumas occuring of a crisis, and for all the social aloofnesss of the materialistic world, what kind of a stakeholder analysis can bear the reality of it – of the world as people have made it to be, in where are the worst possible designs demonstrated of real human actions? Does all the world then need a coroner's wit, to extrapolate any manner of a sense of society?

What if material aloofness is a part of the real problems, in the very real world? Would such a possibility ever be addressed of a social contract on the part of any material society? May a society imagine itself too successful to give a damn?

What if?

And if in such a social world, what to say about customer support?

This thesis has arrived at its end.

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]

Calculating with CORBA – A Showy Prognostication Of Rational Numbers, Computations, and Communications in Application Systems

Reading over an embarrasingly obtuse description that I had written, one day in another place, about a software system that I was referring to as igneous-math, I would like to denote henceforward that the article was much of an effort to describe a simple sense of novelty about the 'ratio' type as implemented in Common Lisp. Without immediately producing a study of IEEE standards for representing floating point decimal values in computing systems, and without any lengthy sidebar as to comment to a concept of fixed point arithmetic as developed in Forth, I recall that my initial thesis had centered on the very limits of finite data registers in computational machines.

In the following article, the author will endeavor again to circumnavigate any specific consideration with regards to computing, instead to focus about some concepts of commumications as developed with regards to CORBA.

Assuming a fixed-size data register, in any single numeric computation – whether of a 24 bit, 32 bit, 64 bit, or other bit length of numeric encoding – any number may be represented in a precision bounded by the size of the data register in which the number is encoded.

This article will not go at length to juxtapose different methods of discrete digital encoding of numeric values, as whether for encoding of natural numbers, signed integers, unsigned integers, fixed point decimal numeric values, floating point decimal values, numeric ratios, or complex numbers. Excepting the field of ratios and the field of complex numbers, each other of those topics may be referenced immediately onto the Common Data Representation (CDR) format as standardized in specifications about the Common Object Request Broker Architecture (CORBA). Though that may not serve as to describe such topics in any manner of a comprehensive detail, but as to reference these topics onto CDR encoding, perhaps it may at least serve as to provide a common point of reference – in regards to numeric computing – principally orthogonal to an implementation of any single programming language or programming architecture.

The CORBA specifications, as publicly described in core specifications documents and as extended in any number of supplemental specifications documents published by the Object Management Group (OMG), moreover as pragmatically augmented with domain-specific case studies described in any discrete number of documents in or outside of the OMG specifications set, moreover as implemented in any number of instances of development tools, then as applied in any singular set of software products – broadly, CORBA provides a platform-agnostc framework for applications, such as may be developed to extend of any number of fundamental CORBA object services – as in regards to developing software components such that may interact via CORBA object services, at an applications layer and – as on a TCP/IP network – may employ methodologies of transport semantics at session (cf. SECIOP) and presentation (cf. ZIOP) layers, as in regards to a view of networked applications projected onto a conventional seven layer model of TCP/IP networking.

In such a context, CORBA serves to provide a single, standardized, baseline object service architecture, such as may be augmented in applications of supplemental CORBA object service specifications.

In regards to applications utilizing CORBA IIOP – IIOP being the Internet Inter-ORB Protocol, principally an extension of the Generalized Inter-ORB Protocol (GIOP) –  applications may apply the Common Data Representation (CDR) format for stream encoding of data values, such as may be reversibly encoded and subsequently decoded onto protocol request sockets and protocol response sockets in a context of CORBA IIOP.

Short of an orthogonal concern with regards to encoding of object references, the CDR encoding format provides for an encoding of atomic, primitive numeric values – an encoding standardized essentially onto stream objects, principally in a manner independent of any single microcontroller implementation, but however dependent on a streams-oriented communications media. Though perhaps the CORBA architecture may serve to encapsulate much of the nature of the stream based encoding of data values in IIOP, but inasmuch as that an IIOP application utilizes TCP sockets for its implementation, the IIOP implementation therefore utilizes a stream based encoding. Whether GIOP may be extended, alternately, as to develop any more computationally limited encoding – such as perhaps to develop an encoding for protocol data values onto an I²C bus, as may be for application within a light-duty parallel computing framework, or alternately, as to develop an encoding method for GIOP onto shared memory segments within a process model of any single operating system – the CDR encoding onto IIOP serves to provide a standard encoding for atomic data values, moreover CDR providing a basis for encoding of object references and any number of application-specific data values, in CORBA applications.

Thus, as towards developing a platform-agnostic view of applications of computing machines, it may be fortuitious to make reference to the CORBA architecture – even in so limited a regards as in reference to the CDR encoding for primitive numeric values.

Concerning the CDR encoding for any single data value onto a communication stream, the CDR encoding may be observed as being compatible with so many machine-specific encoding methods for encoding of data values onto finite memory registers, data values as may likewise transmitted across finite processor bus channels within any single computing machine. Certainly, the communications of a data value – as within a CORBA application framework – would not cease at the transmittal of the data value to or from an IIOP application socket.

Towards a perspective of an implementation of CORBA, the CORBA implementation's own concerns – with regards to communication services – might not extend much further than as to provide an interface for encoding and decoding of data values onto CORBA data channels, in a manner however orchestrated with CORBA object adapters. The trope as that CORBA is for application in regards to middleware services – aside to any suggestion, to which the author may take some exception, as if CORBA was not trendy, any more – it does not serve to say much, at all, as to how a computing machine may apply any single data value, once a data value is transmitted over a CORBA object services network. Naturally, CORBA is a feature of a communications domain. In a manner of a domain-oriented view, CORBA dovetails with a domain of computer operating systems and a domain of microcontroller design, furthermore – as inasmuch as that a microcontroller provides computing services to an operating system, and as that an operating system may be applied as to provide computing services to a CORBA application.

How, then, is UNIX not relevant to CORBA applications?

The author of this article being how immediately preoccupied of developing a thesis with regards to the Common Lisp programming language, the FreeBSD operating system, and the potential for applications of CORBA in networked computing,  but perhaps it may seem as though the author is simply distracted of some few archaic trends in the social universe. The author would not propose to suggest any too narrowly deterministic model of such a thesis, whether or not is may be easily proved to be of a computationally sound and comprehensive architecture for computing in any arbitrary networked systems environment. Common Lisp has perhaps not been a great favorite for applications programming, however it may momentarily serves an academic end, as in a manner of thesis development. It might be estimated, moreover, that most theses developed about Common Lisp would be developed, likewise, as theses about concepts of artificial intelligence – logically, with regards to theses describing of applications of logic in mathematics and in computing systems. Perhaps it has not been since the 1970s and 1980s that Common Lisp development was shaped of microprocessor development. Across the popular AI Winter of the era, but perhaps the old scrolls have not all been lost to the shifting ice of the populist glacier.

As though lost in the library of historic record – but AI Memo 514 is certainly no manner of a Cardiff giant. If it may be a memo of an academia in which the plain logic of microprocessor design was paramount – but perhaps the contemporary computing market may seem all preoccupied of so many novel products of contemporary microprocessor manufacture, if not of applications of the newest high-speed microcontrollers and software designs in all the novel, new commercial systems. In regards to how so many novel, new toys are applied to present any manner of noise to contemporary engineering trades, but if it may be simply a manifestation of a lot of marketing fluff atop a lot of repetitive iterations in social development, how novel is a simple endeavor to disembark of the sollubrious consumerism and recover whatever remains of the sciences aside the grand industrial merry-go-round?

It might seem as if it was only a metaphor of a brass ring, a token, a trinket grabbed in a singular merry-go-round's long spin? Is it to a metaphor of a trophy, then, ere it is returned to the vendor's brass ring dispensor? If there is not a metaphysics of such a commercial mechanics, perhaps Whitehead's thesis really ever was disproved? May the circus resume, fortwith, if there is no more of a meaning beyond so many singular objects of materialism.

Before returning to this thesis, the author denotes a concept of pi in which pi is calculated as a ratio.

Though perhaps not all definitions of number would include ratio as a type of number, but as for that a ratio may be defined as a type of rational number, it may be a type of number of some relevance for application in computations onto other types of rational number. Sure, then, between concerns of computation and of measurement, some variance in measurment may entail some of a variance in computation. In regards to variance of physical measurements in physical systems, and considering as that a discrete measurement – a measurement of any estimable precision – may be applied in a computational model, applied as towards calculating any intermediate numeric values as may be, lastly, applied in a physical analysis or physical design of a system, and though it may seem practically naive to assume a perfect measurement may be provided to any computational system, but insomuch as that a computational system may produce a predictable set of consequent computations, as given a known set of initial measurements and a discrete formula for calculations, a computational system should not itself be assumed to operate at variance of any set of initial measurment values.

If there may seem to be a commercial novelty of the Common Lisp functions, 'rational' and 'rationalize', those two functions alone may be applird as a computational entry point – of each, seperately so – to perform all intermediate calculations within a computing machine as in calculations with rational numbers. There may be, in that, likewise a toss of the hat with regards to fixed-point numeric calculations in Forth. Perhaps it may be said as to "Go further," moreover, that any immediately fixed-point numeric value may be converted to a ratio numeric value, as to conduct any subsequent calculations wholly onto rational numbers, whether or not producing a decimal number for numeric denotation as a consequent value.

It is not unprecedented: That a computing machine may usefully produce calculations deriving of rational numbers. In an immediate manner, a computer of a finite memory may not actually contain an irrational number, except that an irrational number is encoded of rational quantities. A concept of irrational number should not be removed from numbee theory, of course! It is simply not a concept occurring in computations within finine memory spaces.

It is not to merely make a drab show, therefore, if a rational number may be calculated as estimating a built-in decimal value of pi to a rational numeric constant. Such a constant, rational value may be applied intermediate computations wholly onto rational numbers. The rational numbers computer may only need convert any decimal input values into a ratio format, then to produce a decimal representation – to any single consequent precision – of any numbers calculated finally of the rational computation.

Of course, this does not indicate any trivial methodology for rational numeric computations onto transcendental functions. So far as that the triginometric transcendental functions may be derived of a rational estimate of pi, as on a unit circle, there may be a channel for computations with rational numbers in those transndental functions. The author, regrettably, is not as immediately familiar with calculations of Euler's constant.

Towards a representation of ratio numeric values and complex numeric values – no mere propaganda, the Common Lisp type system providing definitions of such numeric types, in computing – of course, it may be a trivial affair, to define an IDL module, an IDL interface, and finally an IDL data type in which a platform-agnostic definition of each of the ratio or of complex number numeric types may be provided, in a computing system. That being denoted as towards a consideration of a transport level encoding of numeric values, but it may not seem to say an immediate bunch as towards an algorithmic, if not functional view of computing

This article, presently, returns to a thesis about CORBA.

Of course, CORBA IDL itself is not the computing element of a CORBA system. Inasmuch as that an implementation of a CORBA IDL module may be developed in an application programming language, then applied within an object adapters system, CORBA IDL may serve something of a complete, modular role in regards to communications among computing systems. This article has denoted, albeit somewhat obliquely, the CDR encoding for data values in an IIOP framework. Likewise, as in regards to the subclauses of the CORBA core specifications as in which CDR and IIOP are described, it may be said to amount to a much of a description of a platform-agnostic communications model, such as is defined in a manner for application within a broader, platform-agnostic object services framework as may be denoted, broadly: CORBA.

May it be, then, as if to limit the potential applications of CORBA frameworks, if the computational features of CORBA systems may not often be found as described in so much of specific detail as of the CORBA communications model itself? One may wish to speculate as to how the platform-agnostic nature of CORBA specifications may seem to effectively obfuscate any single CORBA implementations from immediate duplication without limits of immediate licensing agreements. In some regards, such a coincidence could be quite fortuitous, overall. Inasmuch as CORBA may find an application in defense systems, such applications should probably not be danced out for any idle opportunism, however any CORBA applications may be momentarily denoted of a popular discourse. However analogously, if CORBA may be estimated as to find applications in some of social infrastructure systems – such that may seem however estimably possible, as in consideration of specifications defining platform-agnostic applications of CORBA in telecommunications systems – but this says almost nothing with regards to any manner of actual computing systems. Not to offend the reader with the author's own simple obtuseness: A communications specification is not a microprocessor, just as much as a pie plate is not a peach pie.

Sure, a discrete number of peaches may be applied in preparing any discrete number of peach pies, at any estimable formula of efficiency and other results. Analogously, the CORBA specifications are not either like recipes for microcontroller applications. (Ed. note: There should be a cute metaphor to Hexbugs(R), here. Though it might seem to startle a reader, if juxtaposed to the fantastic, fictional Replicators of the Stagate SG-1 universe, in science fiction literature, but the metaphor of a microchip-sized automoton of a bounding character, outside of any too far Arachnid-like species of science fiction creature, the simple ant-like Hexbug Nano(R), as a metaphor, could be apropos.)

So, a student of computing might feel in some ways stymied of the communications-oriented CORBA specifications. The proverbial magic of CORBA may not be insomuch in the proverbial network chatter of a CORBA object system.

Thoughts - Nomenclature and Taxonomy

As a topic that I've found some concern about: Even in so much as developing my own set of notes at Evernote -- and marking such notes in any ways meaningfully, with labeled tags -- I've begun to develop a sort of an ad hoc taxonomy about a number of concepts in computing.

Though I've not lately been refreshing my own study of the bibliography of taxonomy, it's a topic that I'm aware of as it existing, with potential applications in a number of theoretical contexts, including: Topic Maps, as in reference to the XTM topic maps format and Ontopia; the Simple Knowledge Organization System (SKOS), as in reference to RDF, RDF Schema, and the Web Ontology Language (OWL); the Darwin Information Typing Architecture (DITA) as in reference to types of DITA topic elements. In an applications sense, I've observed that a concept of taxonomy may be relevant in regards to web services for content curation, web content annotation, and web content development, as in reference to both of Evernote and Diigo.

Both of Evernote and Diigo allow for annotation of web content. Evernote might seem to provide something more of a container view of web content, juxtaposed to Diigo. Diigo might seem to be more readily usable, at desktop PCs, for web content annotation. Evernote and Diigo both provide services towards content development – Diigo, with Diigo outliners, and Evernote with Evernote articles.

Focusing on the "Content tagging" features of each of Evernote and Diigo -- with a momentary reference to the original Annotea project of the World Wide Web Consortium (W3C) -- Evernote allows for hierarchical organization of content tags. This evening, I've noticed one simple example in which that occurs to a particular highlight: Annotating a concept of instruction set architecture, as of any of a Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) or other species of instruction set architecture developed into a tangible microcontroller platform. Orthogonally, there's a concept of instruction set architecture denoted in MARTE 1.1.

To denote each of a concept of CISC and a concept of RISC as being subsumed by a concept of instruction set architecture, it may not seem all of ideally like a perfect taxonomy, but I think it suffices for my own personal notes, in my own Evernote notebooks. That there are any number of instruction set architectures that may not be immediately denoted as either CISC or RISC architectures, there's a whole history of computing that was developed before those terms became en vogue. Some of the literature of the earlier computing might seem particularly clear in developing concepts as with regards to logical microcontroller design, moreover.

I think, the classification of CISC and RISC concepts as being subsumed by a concept of an instruction set architecture, it provides both of a semantically meaningful construction and a flexible construct allowing for later description of instruction set architectures, such as may not be immediately identified as either CISC or RISC architectures -- however anyone may endeavor to define exact limits to a definition of either of those concepts, as implemented in any single, tangible microprocessor.

Of course, a concept of RISC and of CISC may likewise be subsumed of a concept of microprocessor architecture -- as by way of a concept of instruction set architecture.

This article -- which I had wanted to write, originally, about taxonomy -- it is, by now, also an article about concepts of instruction set architecture. The reader might notice that this article, moreover, is absent of any cross references to a Wiki. That's not to snub the WIki editor community, simply the reader may Google any number of these concepts. Personally, I think that my own study is better served with my own application of Evernote, Diigo, and towards a DITA model for content development, not to lead too much into any singular Wiki narrative.

This web log I keep, I think this is just a forum to be a little more chatty about some concepts, essentially outside of any specific social channels, online. I've been trolled, here, exactly once -- therefore, would expect anything similar again. Though I've yet to be trolled here any more than once, I now understand I must understand that I may be trolled, here, at any time. So, I'm naturally going to be a little more edgy-terse in writing at this, my tech web log -- might learn to be more cheerfully natured about the overall "Troll potential" of this supposedly anonymous Internet, though in no immediate sense of warmth for trolling. It sure makes it difficult to write about any cheerful concepts, here. I've a sense, that's by no means "Only Online," either. However momentarily flexible the Internet media might seem, of course, any single page with a comment section might become an instant forum for mud-slinging.

Why is anyone so ad hominem online? I honestly cannot imagine. I'm not one to escalate or deter anyone's own fantastic ideas, as such, either. Does that make me an easy target, online, or just a subtle observer of semantics, though? So sure, maybe sometimes I draw fire from an Internet troll. Big loss, huh?


Further than defining a correlation between a concept of CISC architectures, and a concept of RISC architectures, with both concepts being subsumed of a concept of Instruction Set Architectures -- and this, being represented simply in a set of Evernote 'tags' -- that concept then being subsumed of a concept of Microprocessor Architecture, I notice that all of these concepts may seem to fit well in an overall taxonomy of nomenclature about computing.  My being a student not so much of the nomenclature as much as of concepts denoted of the nomenclature, in computing, I wouldn't want to be tedious about nomenclature. I think, it's an idea towards keeping so much as my own webliography well organized -- not to say of any broader sense of bibliography, and how to integrate a bibliography system, and Evernote, and Diigo.

Of course, in thinking furthermore of developing a topic repository model onto DITA, I'm not thinking anything "Like FOLDOC", as FOLDOC is far too friendly a media for such a serious demeanor as I think I must have to keep, in most of communications immediately in the modern world online.  Sometimes, I can't help but have an impression that some lot of the readership might be just waiting to reach out and take a swipe at something -- judging only by previous experiences, no more wishful thinking from me for how people apparently are, online.

FOLDOC publishes a number of reference pages, itself, mostly in a colloquial reference. It's a manner of a topic-oriented reference base, about computing, alternate to Wikipedia.

So, there's already FOLDOC, no rush to develop any excess of an additional topic repository about contemporary concepts in computing -- any repository about information science, the physical sciences, mathematics, logic, and marketing, and anything else that may be defined about computing, including: Concepts of human-computer or human-machine interface design (HCI or HMI, respectively), HCI/HMI accessibility, or plain novelty.

FOLDOC exists, great thing.

Concerning Android App Identities as Represented in the Android OS

One of the challenges facing the development of an integrated bibliography system on the Android platform, simply, arrives of the Android OS' app UID/GID model, moreover Android's application of the Linux filesystems permission model – in any ways augmented, as some documentation may denote, augmented with a mandatory access control (MAC) application extending of SE Linux, in light of the albeit not formally adopted POSIX 1003.1e i.e "POSIX 1e" draft, in Android KitKat and other Android release branches. POSIX 1e finds application in Linux, furthermore, with the Linux process capabilities implementation. Analogously, in the FreeBSD operating system, POSIX 1e find application in the FreeBSD MAC implementation and in the Capsicum implementation.

Not as if to abjectly criticize the Google Android project – the app/filesystem permissions model in KitKat being of some notable inconvenience for file storage to SD card media, in Android platforms – there is probably a logic to the changes made with regards to these features, in Android 4 i.e "Kit Kat" and other Android release branches. (Ed note: cf. Android Content Providers [AndrDeveloperST])  Whatever ways in which the MAC model may be involved in the issue, it may seem to center primarily about app UID specification – the issue of the inonvenience for platform users, as with regards to files that must be accessed with multiple Android apps on a single Android appliance – whether or not specifically to access files stored on external SD card media, logically an orthogonal concern, orthogonal to the permissions model of a Google certified Android appliance's own on-device storage meda, there with further orthogonal reference to filesystem types (bibliography on file).

On the Android platform, app UID and GID is computed at time of app installation[AndrDeveloper]. App UID and GID information on the Android platform is not stored in the common text and shadow files under the /etc directory – common insomuch as with regards to UNIX platforms applying a POSIX and X/Open model. Rather, in one regards, UID and GID information is stored – on the Android platform – as with reference to an 'acct/uid' directory[BD2015]. (Ed. note: See also, the GET_ACCOUNTS manifest permission [AndrAPI_Mperm])

From a developer's perspective, there are application settings available for sharing an app's identity with an existing app, inasmuch as with regards to the sharedUserID attribute [AndrDeveloperPerms] of a single app's APK manifest description. The corresponding sharedUserLabel APK manifest field, moreover, allows for human-readable labeling of apps' shared user ID[AndrAPI_R], Albeit, the sharedUserLabel may be applied to an ambiguous situation – as with regards to that a sharedUserLabel may be specified in one app's APK manifest, but would be applied for a UID shared among multiple apps. This article will not further investigate how the Android OS may establish a systematic precedence to shared user labels, as in a conflict of differring sharedUserLabel specifications for a single sharedUserID.

In addition to the sharedUserID APK manifest attribute, the Android API defines a permissionGroup object type [AndrAPI_R], corresonding to a 'permission-group' tag as may be specified in an Android APK manifest file[AndrAPI_RStyleable]

Referring to the reference documentation about these multiply-linked OS features, in Android, it seems there is an Account Service in the Android OS, specifically referencing the GET_ACCOUNTS manifest permission [AndrAPI_Mperm] – perhaps an elusive feature of the Android Operating System, the Android OS Account Service.

There is  inquiry of a topic as with regards to storage of user account information on the Android platform. [OvOp2015]  Probably, the Android OS Account Service may be a topic of a commonly linked reference, as with regards to APK principal peer identity, and UID and GID values computed at time of APK install.

(Ed. Note: Or not. On further study, it seems that the Android Account Service is rather a service for managing a user's web account information, centrally, on any single Android appliance.)

Perhaps this study may be extended of, as with regards to applying Kerberos as a neteork peer authentication service on Android appliances. There is some of an existing work, with regards to implementing Kerberos services on the Android platform (bibliography on file), though perhaps nothing immediately about whether or not a network admin should allow authentication to a network service, e.g SSH, with a Kerberos ticket from a thin client appliance – an orthogonal topic, certainly. For web apps, of course there's OAuth/OAuth2.

 [Article Draft Nr. 2]

Webliography

[Anderson2013] http://www.all-things-android.com/content/deeper-look-android-application-permissions
[BD2015] http://boundarydevices.com/android-security-part-1-application-signatures-permissions/
[AndrDeveloperPerms] http://developer.android.com/guide/topics/security/permissions.html
[AndrAPI_R] http://developer.android.com/reference/android/R.attr.html
[AndrAPI_RStyleable] http://developer.android.com/reference/android/R.styleable.html#AndroidManifestPermissionGroup
[AndrDeveloperST] http://developer.android.com/training/articles/security-tips.html
[AndrAPI_Mperm] http://developer.android.com/reference/android/Manifest.permission.html
[OvOp2015] http://android.stackexchange.com/questions/74969/where-is-user-group-id-info-stored-on-android-and-how-do-i-inerpret-it

Lua - A Comment

Though I've been considering to begin taking a closer look at EFL WebKit potentially for application with Common Lisp, but presently I've become somewhat distracted of the network configuration on my small LAN. Towards considering a scripting language -- alternate to SH -- for automating a time-based iterative function on the LAN gateway, I've not considered Common Lisp as an option for this application. Though I think Common Lisp has a lot to offer to systems programming, but I think it may be a little much to apply a complete Common Lisp implementation for simply automating such a function on the LAN gateway.

Considering scripting languages, I'm young enough in years to remember when PERL was first becoming a popular scripting language. I remember, likewise, my own difficulty with making sense of the affability with which PERL's baroque syntax was presented, in popular discourse. Presently, I don't believe a person  should ever have to indulge in any manner of intellectual gymnastics, if to understand the syntax and semantics of an interpreted programming language. I don't have any great sense of appreciation about the eclectic nature of PERL. Candidly, I think it's more a novelty than a necessity. I don't find it to be a particularly helpful novelty, either.

So, I'm also going to take a break from so much as considering to develop any applications of Common Lisp. I'm sure Common Lisp is great for making adventures about computer science.

I've glanced at the Ruby language. I've heard that Ruby is applied in Puppet Labs' Puppet tools. Not to rain on anyone's fair, as far as scripting languages, I'm thinking to favor Lua instead.

Lua is a programming language with a few applications that I know of. The first one I've thought of, of late, has been the application of Lua in the block-oriented builder game universe of the Minetest platform. Then again, there's also the Texas Instruments N-Spire graphing calculators, which feature a Lua interpreter. Even in this era of the Phablet computer, I think that the N-Spire calculators are some really profound calculators. I'm impressed with their possible applications in laboratory science and in mathematics.

This evening, I've also found a couple of implementations of Lua onto CORBA, and a note about a Lua scripting extension for Nginx. The latter could be of use as towards developing a manner of a "Web Social" presentation model onto Minetest, but that's in looking ahead.

Searching the FreeBSD baseline packages repository, I see that there are a number of FreeBSD ports available for programming with Lua. Towards adopting Lua in integrated development environments, there's also an Lua-mode for Emacs, and -- in the Eclipse IDE -- there's also the Lua Development Tools platform, previously Koneki.

There are a number of books about programming with Lua, at Safari Books Online. Reader's interests may vary.

There are also Lua interpreters available on the Android platform.

So, it should be to a great lot of fun. Why, then, am I writing a web log article instead of writing my first lines of Lua code?  Is it that I am bewildered that Common Lisp, for all its Turing Completeness, still does not re-emerge any further from its AI Winter in Comp. Sci academia and into the commercial market? Am I perhaps a bit disconcerted by the character of same Comp Sci academia, itself, in some that I have seen of the same, and way too personally so?

I think both of those are why I would like to write a while longer, before studying much more in detail about Lua -- but of such a rough time veritably on the dark side of the moon, what is there to every write usefully of it?

Not a lot.

Cloning WebKit in a Few Easy Steps

The Git changeset repository developed by the WebKit project is not a small Git chanegset repository. In order to Git clone the WebKit Git repository for software development, an incremental Git fetch may be useful. 

An intermediary Git gc call may serve to optimize the Git repository clone, before the final 'unshallow' Git fetch procedure.

Example: Incremental Git clone/fetch - WebKit Git repository.

#!/bin/sh

WHENCE="git://git.webkit.org/WebKit.git"
WHERE="webkit"

git clone --depth=1 "$WHENCE" "${WHERE}"

cd $WHERE

for LIM in 100 1000 5000 10000 20000 40000 60000; do
    git fetch --depth="$LIM"
done

git gc --aggressive --prune=all

exec git fetch --unshallow

Configuring Git index-pack

The following configuration may not be ideally optimal. The following configuration settings may serve to alleviate some conditions that may otherwise cause Git index-pack to fail when repacking the data of WebKit source code repository.

git config --global pack.deltaCacheSize 512m
git config --global pack.deltaCacheLimit 5000
git config --global pack.windowMemory 100m
git config --global pack.packSizeLimit 100m

Post-Checkout Configuration

The WebKit Git repository is constructed effectively as a Git proxy onto the WebKit SVN repository. In order to draw changes directly from the WebKit SVN repository, the WebKit project has provided a utility shell command [cross reference]

cd ${WHENCE}
Tools/Scripts/webkit-patch setup-git-clone

For developing with the EFL WebKit integration, a shell command is available as an initial dependency management utility [cross reference]

${WHENCE}/Tools/efl/install-dependencies

 The "See Also" Section

Developers may wish to refer to more detailed documentation about Git

• Tips and Tricks for using Git with WebKit. WebKit Trac Wiki (2013)
• Chacon, Scott and Ben Straub. Pro Git. second edition. Apress (2014)

For further documentation about developing with the EFL integration for WebKit

• EFL Port of WebKit. WebKit Trac Wiki (2015)
• EFL Documentation. Englightenment Main
• Haitzler, Carsten. Tizen Native Display Layer - EFL, Architecture and Usage (2012)
• Documentation for EWebkit2 (version 1.11.0)

EFL is a core feature of the Tizen framework. Additional documentation may be available about applications of EFL, with reference to Tizen

• Graphics. Tizen Developers
• Cairo. Tizen Developers
• Elementary GL Helper functions. Tizen Native API
• Holwerda, Thom. Samsung Sponsors Enlightenment, EFL Development (2009)

Towards Developing a DITA Editing Platform on FreeBSD

Having developed a certain sense of interest with regards to writing technical documentation, I've been studying periodically about the Darwin Information Typing Architecture (DITA). There are a number of things that I would like to highlight about DITA, as in a sense of a thesis document – I've tried to collect my notes, as such, with Evernote. Thus far, I have been unable to write any single thesis document about the topic, rather developing only a series of itemized lists of notes, and a small bibliography.

Presently, I think it may be as well to begin writing some narrative text about DITA. Although I may not feel as able to write fluidly, in a digital media – as juxtaposed to a media of graphite and paper, with clipboard, to an older style of desktop writing appliance – but it is surely easier to share a work of writing produced in a legible digital font – here juxtaposed to my own cursive handwriting and ad hoc visual layout approaches, as when writing with pencil on paper.  Sure, I have begun to sketch out an idea for a more fluid style of sketching in a digital media, but it would need some work in regards to ergonomic presentation and editing of vector graphics, and therefore may depend on software not yet developed for the Common Lisp Interface Manager (CLIM). Presently, I am more preoccupied of developing a workflow towards DITA editing with free/open source software (FOSS) tools. Though I have looked at both of the XXE XML editor and OxygenXML for a DITA workflow, I would like to start writing DITA with a platform more familiar to me. Personally, I'm comfortable with Emacs and pSGML.

In regards to any manner of perhaps esoteric features of DITA – such as, DITA linking, DITA content replacement, and any broadly semantic qualities of DITA's  topic element classes – it might not seem that a baseline Emacs + pSGML environment could be completely sufficient, If applied primarily as a DITA editing enviromment. The Emacs + pSGML platform, of course, can be extended with Emacs Lisp. Although Emacs, in turn, may not seem like a very rigorous programming enviromment,  as when juxtaposed to the Eclipse IDE or IntelliJ IDEA platforms – both of which are developed, primarily, in the Java(R) programming language – but I think there is a manner of an incentive in the simple convenience of the interactive, functional command interface of Emacs + pSGML. It may seem to be enough that I might not be excessively distraught about the absence of programmatic rigour in the Emacs Lisp programming language, juxtaposed to Oracle's Java(R).

So, but in that I would not wish to develop an manner of an ivory tower of this concept, and I will be writing with Emacs on a FreeBSD desktop, I think it needs a a sense of a project, in itself. I propose that a FreeBSD port can be developed of each of: The DITA 1.2 Document Type Definition (DTD) files, there integrating with the XML entity resolver's configuration on FreeBSD; the DITA Open Toolit, likewise to be integrated with the host's XML entity resolver, moreover to be applied with the user's own ASF Ant configuration. If anything analogous to the Comprehensive PERL Archive Network (CPAN) may be developed, moreover, as to provide a software distribution service for extensions to the DITA DTDs and DITA Open Toolkit (DITA OT) XML stylesheets, perhaps such a thing may be anyhow designed onto CORBA services, moreover the CORBA Component Model (CCM), if not Java(R) and OSGi services. Of course, from an end user's perspective, that might be secondary to the availability of a FreeBSD port for each of those two existing components, respectively the DITA DTDs and DITA OT.

Fourthly, as towards a concept of applying DITA in an open documentation system, there is a simple concept of a topic repository model that may be developed, in a manner of writing DITA as like for a sort of an – albeit not primarily web-based, and insamuch not web-editable – Wiki-like format. Though it may seem to loose something of a popular incentive, for it not being a web-editable format, but inasmuch as that a DITA editing platform may serve to provide a manner of editing support not easily provided altogether with a web-based interface environment, then perhaps there may be an adequate "up side" to the design decision, as such.

Immediately, I am somewhat distracted of the tedium of making a complete Git clone of the WebKit source code repository – perhaps this is referred to as multi-tasking. It seems that the initial Git fetch must be run incrementally, onto that same source code repository. It's presently at `--depth=20000`, in no small detail. I have referenced only a couple of forum topics [Matthews 2010][midtiby2011], to try to resolve that a complete `git clone` onto that source code repository has consistently has failed. Proceeding to to a `git fetch` at `--depth=60000`, the Git incremental-clone procedure succeeds, so far.

Ed. Note: There's also something to write about `git gc`

To Evernote like DITA

I wish a DITA editing tool could be as convenient to write with as Evernote.

Meanwhile:  FELDSPAR Model Catalog – Towards a reference manual (Σ)

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.

Considering Bibliography and Filesystems

While Git clones EFL WebKit onto my GraniteLAN, there is a short while as to develop a thought towards a concept of bibliography: That in the known universe, there exists a book about SysML, and there exists an article towards a mathematical perspective of UML. A mathematical perspective of such a topic, perhaps, may be presented as towards something of a literary discussion about a sense of a philosophical and practical relevance of the Metaobject Famework (MOF), and the corresponding metamodels of UML and SysML as dialects of systems modeling, such as may be applied moreover towards a systems design.

I'll try to develop a logical model of a concept, presently, as towards developing a logical model of software components, abstractly, and of components bundled materially in the EFL WebKit changeset repository – a changeset repository stored and accessible with Git.

Preliminary to developing a UML modeling profile for software source code components, I would firstly like to share a set of notes that I've collected as with regards to bibliography. I'm afraid that it cannot be a trivial effort, however, as to begin a thesis about bibliography, forthwith. Presently, there is a matter of the bibliography for any thesis about bibliography.

The article – as towards a mathematical perspective of UML, in the known universe –  the article, in a PDF edition of its presently unnamed publication, it is presently located in a private Git repository on my notebook laptop.  I had moved the file to there – effectively, relocating the file from its initial on-LAN location, then stored on the internal filesystem of my own academic dashboard of a tablet computer, moving it then to the FreeBSD UFS filesystem on my Notebook – that procedure, as when I was trying out git-annex as a file synchronization tool. Not to short git-annex of attention, I don't believe a Git repository may be an ideal resource for a mobile filesystem. The 'dot-git' metadata directory of a source tree managed with Git, that may seem to present something of a waste of limited mobile storage space, as it is for storage of data that may not be immediately accesed by a Git user, outside of each individual changeset registrstion.

Since the time of making an initial study about git-annex, approximately one week ago, I've read a small amount of literature about SparkleShare. I wonder, now, as SparkleShare implements a manner of a virtual filesystem, may it be approached as to develop a manner of a CORBA filesystem service framework? SpakleShare is available as free/open source software, juxtaposed to Dropbox, Box.net, or similar closed source, web-oriented Cloud Storage services.

This morning, while developing an outline about networked filesystems available on FreeBSD, I'd read some little about GlusterFS, and some little more about network services available to a model of classical UNIX networking. Though, personally, I am not immediately decided about applying either GlusterFS or NFS on my GraniteLAN, this afternoon, however I'm considering both of those networked filesystem models – as towards a manner of a DevOps regards – for application in integration testing and continuous availability i.e software distribution, but on a local area network (LAN) only, of a custom compiled FreeBSD 10.2 kernel and FreeBSD 10.2 base system on GraniteLAN.

So. There's to a service oriented view of filesystem services – as in a manner, a view corresponding with a generic concept of "File", howwver applied as onto a concept of a "Private network." There are the GlusferFS and NFS network filesystems, and alternately, SparkleShare as a centralized virtual filesystem.

Three types of filesystem – it might be enough as with which one may develop a manner of an outline of a thesis article. There might be a concept of mathematical topology, correspondingly developed – perhaps, towards an abstraction about data and computation, and a conept about illustrating a graph of data.

[Draft nr. 5]


Some notes about Bibliography, focusing on bibliographical tools

• Mendeley Desktop (Microsoft Windows, version 1.14)
• When importing a BibTeX file, in regards to attachments (files), Mendeley Desktop does not parse relative filenames as expected. 
• If an attachment is referenced in the BibTeX file with a relative pathname -- such as when the BibTeX file is generated with Eratosthenes, then as when attaching a document to a BibTeX entry -- the attachment will not be added to the user's Mendeley files, as expected. Mendeley, instead, will report as if the file does not exist. 
• A workaround exists for this unexpected software behavior: To remove the "Not found" attachment's entry, in each Mendeley bibliography entry, then to attach each file manually
• When saving the user's bibliographies in BibTeX format:
• Effectively, the files are saved in read-only format. Changes to the files will be overwritten by Mendeley Desktop
• For a set of bibliography files saved by Mendeley Desktop into a directory 'bibsync', the BibTeX *.bib files saved within 'bibsync' will change in unexpected ways, over time
• Mendeley Desktop does not always save the set of  BibTeX entries in the same order of entry, within each file, at each time of synchronization
• If the 'bibsync' directory is managed within an SCCM repository, this will result in file changes, though the BibTeX entries themselves may not have changed, in any single one.
•  If the user has configured Mendeley Desktop to organize the user's bibliography attachments, as to save the files within a directory 'bibsync/files', then in each entry in 'bibsync/*.bib', every attached file within 'bibsync/files'will be referenced with an absolute pathname as would be generated on the filesystem or origin.
• This may seem to present a minor challenge, as in regards to utilizing the generated BibTeX files with services not including Mendeley Desktop -- such as when the bibliography files are synchronized into an SCCM repository, or if the bibliography files would be posted to any single web service
• Eratosthenes (Android)
• Eratosthenes Wiki [Bitbucket]
• Eratosthenes Issue Tracker [Bitbucket]
• Not open source
• Not uncommon, on Andoid
• Supports bibliography formats generated with JabRef, BibDesk, and Eratosthenes
• Great UI
• May be difficult to synchronize between tablet and desktop
• Tried: Synchronizing bibliography metadata and files, using git-annex
• Though git-annex has its applications, but in considering the limited filesystem storage capacity available of thin client mobile appliances, the dot-git repository of a git-annex repository consumes storage space to no great effect. This is more pronounced, perhaps, for storage of binary formatted files, such as of documents in the Adobe PDF format
• Unavailable, presently: GlusterFS on Android
• See also: CynaogenMod
• Available, but with reservations: Dropbox
• A user's Dropbox storage is manageable via the central DropBox web site, or on filesystems with the user's central/cloud DropBox storage completely synchronized to the filesystem
• Synchronization not obviously available for Android
• Synchronization not manageable by the LAN administrator
• Unavailable, presently: Sparkleshare on Android

On Cloning EFL WebKit

EFL WebKit is certainly not a small toolkit to Git clone, in its full Git changeset repository.

At 37% of changeset data transmitted, the repository data amounts to so much of 3.41 GB, in a quantitative measure.

Cloning the EFL WebKit source repository - 3.4 GB at 37%

I'm certain there's something that can be applied to simplify its source tree, but it might need a sketch or two in UML format -- moreover, a UML profile for illustrating inter-component dependencies onto a SysML block diagram.

Presently, it has thoroughly bogged down my network uplink, thus making this web log entry a little more difficult to edit. So, there won't be much to show here, in this article's draft nr. 1.

Update: On review of the ewebkit/webkit repository at GitHub, juxtaposed to the WebKit SVN repository (e.g. Source/WebKit2/efl/) it seems that there's a certain lack of synchronization with the repository a GitHub. Furtthermore,  the SVN repository would be the more up-to-date source code repository, assuming a sense of trust about the "Last update" timestamps on the files.

It may seem peculiar that the EFL WebKit developers would not keep the repository up-to-date at GitHub. Regardless, the baseline WebKit SVN repository may be preferred, or the baseline WebKit Git repository -- at which point, the WebKit 'checkout' documentation may be relevant. As a further alternative, a Git repository may be developed as manner of a changeset proxy onto the SVN repository, using 'git-svn'.

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.