Towards developing a model for graphical desktop applications on a FreeBSD operating system, proceeding in a manner by in large independent of any single, existing project, as such -- e.g. such as PC-BSD, a distribution of the FreeBSD base system, with distribution-specific extensions, catered towards desktop computing -- simply, in beginning with the FreeBSD base system, I've been focusing on developing at least a single "Known good" configuration. Before proceeding to describe such configuration, some disclaimers may be in order.
This is not as though to make any manner of a radical response to the emergence of Linux distributions, in any of mobile, desktop, and network service computing platforms. Neither is it as though to try to "Steal thunder" from any of the commercial institutions developing, each, their own proprietary operating systems -- such as Microsoft and Oracle, inasmuch as Oracle had acquired Sun Microsystems, thereby acquiring commercial distribution rights for the Solaris operating system. Simply, it's of my own small effort towards extending of any body of existing work, ultimately towards developing any new software products, in developing a multi-platform desktop computing framework out of the FreeBSD base system.
In developing my first FreeBSD desktop installation, which I'm applying in , writing this article, I'd begun with FreeBSD 10.1-RELEASE, installing the operating system from the UEFI-enabled DVD distribution. The laptop to which I've now installed FreeBSD, it's an HP Pavilion x360 notebook -- with touchscreen. The same notebook uses a UEFI firmware stack, and so of course its internal hard disk drive is formatted according to the GPT disk format.
The installation was made not without some initial difficulty. It being a dual-boot installation -- my wishing to retain the Microsoft Windows 8.1 Operating System (OS) in its installation as created by the Original Equipment Manufacturer (OEM) and later updated of my own application installation and system configuration efforts -- so, previous to the FreeBSD installation, I'd used Raxco PerfectDisk in its boot-time and normal disk defragmentation modes. After some small effort, I was able to create enough deallocated free space on the laptop's internal hard disk drive, sufficient to resize the NTFS partition, thus creating a disk space in which I could install FreeBSD. Although the Microsoft Windows 8.1 system information utilities had reported that there was a substantial amount of free space avalable on that same NTFS partition, initially, but -- perhaps, ironically -- something among the OS kernel and/or userspace applications was persistently writing a small number of file data blocks at the very end of the NTFS partition. That made it more or less impossible to install a secondary operating system.
The Microsoft Windows 8.1 built-in defragmenter was not sufficient for moving those file data blocks into any space nearer to the beginning of the partition. With a small further effort, however, I was able to apply Raxco PerfectDisk. then the Microsoft Windows system management console, to gradually create a filesystem area of approximately 175 GB of deallocated disk space.
After rebooting, then making some small changes in the BIOS-like configuration screen on the laptop -- there, enabling legacy BIOS mode, and also enabling the processor's virtualization features, for later application with regards to QEMU and VirtualBox -- thus, I prepared the laptop for UEFI boot to FreeBSD.
I booted the PC, initially, from the FreeBSD installer DVD. I created a FreeBSD root UFS filesystem and a FreeBSD swap partition, the latter having approximately one gigabyte more of data storage space, juxtaposed to the laptop's installed RAM, to a total of approximately 9 GB swap, approximately 168 GB UFS filesystem, all FreeBSD format.
Following the installation, I rebooted the PC. On the HP Pavilion PCs, the "Esc" key is the "Hotkey" for activating the legacy BIOS menu during Power-On System Test (POST). Although the FreeBSD UEFI configuration on my notebook requires a manual input at boot time -- namely as in order to select the FreeBSD UEFI bootloader, presently the second bootloader listed in the "Legacy" boot menu -- that small mater does not seem to be any sort of a notable inconvenience, to me.
Thus, after the installation, the PC made its "first boot" to FreeBSD. Subsequently, I installed the BASH and BASH Completions packages and changed the root user's shell to BASH. Then, I added a non-root user -- UID 1000, towards a convention for non-system user IDs, as applied similarly throughout Debian operating system distributions. I then used 'scp' to copy my default screenrc, bashrc, BASH profile, and bash_logout "Dot" scripts from my LAN gateway onto the notebook, under the non-root user's home directory. Then as the root superuser, I made symbolic links to those files, from under the root user's home directory. Thus, I had installed a baseline terminal environment. I've since installed a small number of additional utilities -- mmv, uemacs, and xstow -- largely for sake of convenience at the shell command line.
Separately, I've installed a small number of developer tools -- initially, Git, SVN, the SVN2Git bridge, and CVSPS. My being by in large comfortable with the Emacs text editor, I've also installed Emacs 24. I should be updating my dot-emacs directory from my own LAN-local Git repositories, shortly. These packages, in particular, I would denote as their being elements of a developer's profile for the FreeBSD PC.
Following that, I've installed X.org, Xinit, a desktop manager (SLIM), a desktop environment (MATE) and a web browser (Firefox, though I'd tried out Chrome and Opera on FreeBSD initially). The installation of the desktop environment, itself, also entailed an installation of a terminal emulator, a calculator, a text editor, a file manager, and some other relatively lightweight utilities.
Of course, throughout this process -- even as soon as installing BASH -- I've had to make some small configuration changes on the host, manually -- such as for some various changes onto /etc/rc.conf, /etc/sysctl.conf, /etc/fstab, and even /etc/udevfs.conf. such as in regards to SHM support for some of Firefox's HTML5 functionality, and in regards to dependencies on fdescfs, dbus services, pty services, etc.
In the process of trying out the Opera browser on FreeBSD -- namely, at Opera version 16, in its present release, as published via the FreeBSD baseline package repository -- I'd also installed the Linux C6 32 bit emulation for FreeBSD. Subsequently, I'd tried to run Opera version 30 in its Linux (amd64) edition -- then, subsequently, a 32 bit distribution of Opera Version 30 for Linux. Though I think it was quite nice to see that there is a 32 bit version of Opera 30 available, for Linux platforms, but -- insofar as concerning the Linux emulation for FreeBSD -- Opera 30 requires some features that, apparently, are not as yet ported into the Linux C6 32 bit emulation for FreeBSD. My being more immediately concerned as to install a usable web browser to the PC, I've installed Firefox, with no subsequent issues.
Presently, on having observed a note towards possibly developing a FreeBSD edition of Firefox OS, I might wish to wonder what specific licensing concerns there could be for redistribution of the nspluginwrapper port. Reviewing Section 7.2 of the FreeBSD Handbook, apparently there's a concern with regards to redistribution of compiled binary versions of the nspluginwrapper port. Towards a transitive concern with regards to Adobe Flash applications, perhaps a project may need to curry the favor of Adobe, itself, if to ensure that an Adobe Flash plugin might be developed for any single web browser on FreeBSD, or perhaps the SWFdec plugin could be more further supported as a third party plugin for Adobe Flash applications. Referring again to the FreeBSD Handbook, it may seem that those are the two primary alternatives available for Flash support in a web browser on FreeBSD. Perhaps, that may serve to present a concern as towards any possibility of applying a Mozilla Gecko application stack for user interactions with regards to web applications, on any manner of a FreeBSD distribution of Firefox OS.
Alternately, in a figurative sense, perhaps one might endeavor to chart a course towards the furthest side of the furthest known minor planet, Pluto, as if there to develop a by-in-large distinct web application framework onto FreeBSD, with minimal local distractions. Perhaps at such a destination, one may propose to apply Steel Bank Common Lisp (SBCL) -- for instance, in focusing about SBCL's compiler optimizations, among other portable ANSI Common Lisp implementations -- and a fork of each of CLORB and McCLIM -- of the latter, focusing on the CLX CLIM Port, in McCLIM.
The same platform could apply the upstream CLX codebase, unforked. Alternately, in any project developing such a platform, the project might endeavor to develop an implementation of the MIT shared memory extension (MIT-SHM) as perhaps towards any more of an ideal sense of efficiency in "Same-host" CLX client applications on X Window servers likewise supporting the MIT-SHM extension. Perhaps it might serve as to minimize data transfers over local socket channels for X Pixmaps, at least, if MIT-SHM may be supported in CLX. Around such a development, perhaps it might be apropos also to develop a memory locking framework for SBCL, such as to prevent password data or other sensitive user data fields from being paged out to disk from within an SBCL runtime process.
Both of the MIT-SHM and the "Unpaged RAM" features would entail something of a matter of -- if a reader may pardon the pun -- addressing memory areas in the SBCL data space. Of course, the MIT-SHM extension might also require an integration directly with C-format XLib libraries -- thus, perhaps creating an awkward situation in which a non-C-language XLib implementation would use only a small modular part of a C-language XLib implementation. however therefore depending on more features of the C-language XLib implementation, so far as functionally depended-on by the single shared module.
The "Unpaged RAM" extension for SBCL would not require any dependencies expressly onto any additional toolkits. As well as with regards to user data security, the "Unpaged RAM" extension might be furthermore applied for purpose of deterministic scheduling in a realtime computing model applying SBCL.
Personally, I've considered reviewing the Enlightment Foundation Libraries (EFL) separately, for such an albeit unlikely project. EFL is licensed under BSD style licensing terms. As an application toolkit, EFL moreover publishes a C interface. Although the Enlightenment DR17 window manager, itself, might be somehow difficult to configure for some FreeBSD PC environments, but perhaps it could al work out better on mobile. EFL is used in the Samsung Tizen platform, after all. There's also EFL WebKit -- there, to yet another concern with regards to web browsers ostensibly on FreeBSD, furthermore towards some more of a concern with regards to toolchains. EFL WebKit uses CMake.
The author is not immediately certain if any of this would be any easier to "Parse" if it was all formatted in a succinct RDF graph, instead. Perhaps it might seem "Too easy," in such succinct rendition.
No comments:
Post a Comment