Sunday, September 29, 2013

This posting is derived from a convergence of several discussions I have been having in a wide variety of places.

Background:

I trained in Computer Science and Biological Sciences at the same time in the early 1970's. There are some interesting convergences between the two in some recent developments.

My thesis here is that complex organisms developed differentiated tissue systems (organs) in response to a need for robustness and continued operation (health) in the face of complex and unknowable challenges. The computing environment has similarities to a complex organism, such that differentiated tissues (operating environments) are needed to preserve operations in the face of significant and unknown challenges.

This quoted partial posting, is from a discussion on the merits/demerits of maintaining a separation between one part of the computer's data store and another. There is history and experience favoring both sides of the argument, however some of those opposed to maintaining the separation are being dismissive of some of the concerns of those in favor of the separation.

On Linux based operating systems computer files are organized in a single hierarchy (whereas on Windows based operating systems the files are organized in multiple separate disk structures – within each Windows disk, files are stored in similar hierarchical structures.) Linux does, in fact, have multiple disk structures, but they are, by default, all linked together in a single tree. With a bit of effort, Windows can also be setup to provide a unified tree.

     The root of the filesystem tree is generally a disk structure equivalent to the Windows “C:” drive, and the argument revolves around whether or not major parts of the files required for user use (such as the Windows “C:\Program Files” folder) should be on a separate disk partition from the files required for the system to boot up (such as may be found in the Windows “C:\Windows”folder.)
On 09/29/2013 07:58 AM, VAH wrote:
...
 > things were broken way before that. As much as I hate systemd, it is not
 > the root cause of the problem.
 >
 > The problems were caused by people saying that separate /usr was a good
 > idea, so / would not fill up and similar idiocies. The problems were
 > caused by people saying that lvm is a good idea - for desktops. Those
 > people who are fighting against the kernel auto assembling raids are to
 > blame too.
 >
 > Systemd is just another point in a very long list.
 > 

The usr filesystem was separate from root from the very early days of UNIX. Disks were tiny (compared to today) and spreading certain things across separate spindles provided major benefits. Certainly, the original need to require a separate usr went away fairly quickly, but other benefits continued to encourage a separation between root and usr. [Among the chief advantages is the ability to mount a separate usr filesystem in a read-only mode, helping to prevent intentional or un-intentional changes to the programs.]

The var filesystem was for variable system data, and was never terribly big and its inclusion on the root volume happened. The home filesystem became traditionally separate because data expands to fill all available space, and users collect things.

Networking made it possible to have home entirely off system, and diskless workstations ruled for a while as well.

By the time Linux came along, it was common for boot volumes to not be mounted during normal system operation, but the three filesystem layout (root, usr and home all on separate partitions) was common and workable. As Linux continued to be like Topsy (“she jest growed!”) fragmentation started to occur as "distributions" arose. The "balkanization" of Linux distributions became a real concern to some and standardization efforts were encouraged.  I note for completeness that currently the Linux boot process only has the ability to mount one root partition to start with and the tools and programs necessary to find, prepare and mount the rest of the system files.

The "File System Standard" (FSS) was renamed to the “Filesystem Hierarchy Standard” (FHS) and it was strongly based on the UNIX System V definition (which called for separation of ''usr'' and ''root''.) POSIX added more layers and attempted to bring the various BSD flavors of UNIX into the fold.

The LSB (Linux Standards Base) effort was conceived as superseding all the other efforts, and FHS was folded into the LSB definition. Yet even then a separate ''root'' and ''usr'' distinction survived. Then things started falling apart again - POSIX rose like a phoenix and even the Windows/Intel environment could claim POSIX compliant behavior. The fall of the LSB effort really became evident when the FHS was gutted and certain major players decided to ignore the LSB recommendations.

(Look out, there are some severely mixed metaphors coming and perhaps even some "allegory" Bear with it and you should get the gist of my accusations.)

And now we are here in time. There is no clear definition of what comprises this operating system that is a Linux kernel and a largely GNU based user-land. There are two major X-Window based "Desktop Environments" (DEs) and many less major DEs, and Linux is seen as being "locked in a struggle" with the Microsoft OS's to "win the hearts and minds of the Users."

This is quite scary to many folks who depend on the success of Linux "winning" the so-called war. One of the camps bent on wining the "war" is GNOME. Despite much history and experience that shows that choice and freedom are NOT disadvantages, the mainline GNOME folks have charged ahead on their own in a direction that overrides user choice and seems bound and determined to "outdo" Microsoft at their own game.

As a result, the GNOME Alliance has shattered. The main GNOME army marches on its unfathomable path, and various large chunks have broken off in their own directions (e.g. Cinnamon and Mate) seeking to remain flexible and not incompatible with the KDE and other lesser DE systems.

The breakage of the root and usr filesystem separability may be laid directly at the feet of GNOME. Practically all of the breakage is derived from the GNOME camp. These changes may not, in fact, be deliberate or intended to "defeat" Microsoft, but Ockham's Razor cuts and intention is the simpler explanation.

I am not prone to conspiracy theories, but an examination of the history does show that a few, specific ''entities'' (people and companies) have created this dilemma. A set of changes were introduced in the boot-up process of Linux systems, and some required supporting programs and libraries (DLLs) were placed in the ''usr'' filesystem despite many folks pointing out that this was not a good idea.

I am NOT happy with the situation as it stands. Efforts that I made on behalf of the FOSS community and Linux/GNU in particular are no longer serving to benefit me and the others with whom I thought I shared aspirations.

I am an OS Agnostic/Atheist. I use what works to do what I need to do. My at-home network includes all four (or is that 3.5?) "consumer" OSes.

I have spent quite a bit of effort to have them all work together, but forces seem to be in play that seem determined to "win at all costs" and enforce a computing mono-culture. Such a result is not a good thing. As with biological systems, mono-cultures are more vulnerable to interference and disease. The evolution of differentiated organ systems in more complex (or "higher") forms of life is driven by the need to provide robustness and continued operation in the face of unknown challenges.

This reference to mono-cultures is a bit dated but it is still the case that in the environment less diverse systems are much less able to deal with pollution and invasive species than more diverse environments are. As an analogy, consider the effects of computer malware. The widespread phenomena of malware infection in Microsoft Windows installations is well-known and is generally perceived to be the result of known vulnerabilities being exploited in the Windows mono-culture. While Macintosh and Linux/GNU exploits are not unknown, they are less of a problem because they occur in more robust systems and can be healed quickly. Android devices will become more vulnerable as their numbers grow and fewer users regularly update their devices. There is some inborn resistance though, there are multiple versions of Android in the field, and exploits on one version may not be exploitable on a slightly different version.

To iterate the thesis: robustness and flexibility are required for good "health" and we are facing dangerous challenges.

No comments:

Post a Comment