User:Taxman/BSD and Linux

BSD and Linux are two families of open-source computer operating systems. Both are classed as Unix-like because they have a kernel, internals, and libraries, programmed using algorithms and data structures derived from historic AT&T Unix. The most significant non-technical aspect of both families is their availability as free software.

The BSD and Linux families each consist of several to many distributions (distros). Each distribution is a specific operating system (OS), with a brand name known to the public through advertising or advocacy. Distributions are created or implemented by groups of software programmers known as developers, who can be paid professionals or volunteers, living anywhere in the world that has an Internet connection.

BSD and Linux distributions are selected by brand name and installed by a system administrator (admin), for the benefit of one or more users, who run or execute BSD or Linux application programs. The classification of BSD and Linux distros by installation packaging system, and the differences and issues of distro installations will be discussed in sections below.

A personal or small business computer owner may be both admin and user. As an admin, the owner may have to make a confusing set of choices about which operating system distribution will best suit their computing needs. Such choices exist infrequently for commercial Windows or Macintosh OS's. BSD and Linux distribution choices, however, can be overwhelming in number, and subtle in their differences and specialties. Distributions are sufficiently different that a careless choice can lead to lost productivity. Lost time and effort can result if the OS is used in a way that other users have not thoroughly tested, or if the new admin/user lacks the distro installation and configuration skills typically assumed by the community. Good advice is to choose a distribution that clusters new users with an existing user community doing the same type of computing at the same average skill level.

Scope

 * This article introduces new admin/users to the BSD and Linux experiences, especially as they may be unfamiliar from experiences installing and using the commercial operating systems of Major Software Windows and Apple Macintosh at home, school, and workplace.


 * This article intends to assist admin/users in either making a migration consumer or small business choice among the many BSD and Linux operating systems, or choosing to keep their current OS. (Medium and large businesses hire BSD or Linux admins who are not new users.)


 * Also this article attempts to clarify the general similarities and differences between BSD and Linux families, with specific differences highlighted by examples comparing distributions sampled from each family.


 * The creation of totally free BSD and Linux OS software costing over a billion dollars in person hours to develop commercially, raises totally new economic issues for existing software businesses, including "Major Software"* the world's largest corporation. Will Major Software's patents crush Linux development just when it gets really popular? Will BSD developers cut a deal with Major Software to avoid a software patent lawsuit? Will BSD developers agree to charge for every copy of BSD? And will that be the end of free software? (*The purpose of this obvious alias is to hide out from search engines, and help prevent this article from becoming about Major Software instead of BSD and Linux)


 * Finally, this article attempts to parse the phenomenon of OS advocacy by explaining it, describing the problems it causes, and neutrally summarizing the user group positions of pro and con issue advocates.

Readers are assumed to have previously used computer applications such as browsers and word processors, and to have installed, reinstalled, upgraded, or at least configured applications for a desktop commercial operating system. An example of configuration is changing the home page of a browser. Readers are not assumed to have any knowledge of programming, but are assumed interested in the OS consumer and small business choice issues raised by programming and programming businesses.

Differences and issues are encountered by admin/users during several BSD and Linux system implementation phases:
 * 1) advocacy
 * 2) packaging systems
 * 3) supported hardware
 * 4) installation
 * 5) configuration
 * 6) administration
 * 7) operation
 * 8) applications

Specific examples can obsolesce rapidly due to competition among distribution developers. For example, a developer might decide to eliminate a specific difference that they see featured in this article.


 * FreeBSD will be used as a specific BSD distribution example, since it has one of the largest of the BSD distribution communities.
 * Slackware will be used as a specific Linux distribution example, since it is the oldest Linux distribution with several further distribution forks.

FreeBSD vs. Slackware here is only a sample to assist the general comparison of BSD and Linux. A comprehensive comparison is beyond the scope of this article.

General Similarities
Because the BSD vs. Linux debate is so common, it may be easy to forget all the similarities.

BSD and Linux distros are generally available as free downloads, but lacking some proprietary programs that are packaged with the paid versions. Downloading typically very large OS distributions can be difficult to impossible using dialup internet connections. Fortunately many distros are available on CDR discs from free software copy vendors, by internet order and postal mail delivery for a few dollars each. (See the external link DistroWatch.com.)

Specific Similarities
BSD and Linux operating systems share much of the same functionality. They are often able to run programs coded for the other system. When a complete desktop environment, such as GNOME, CDE, XFCE or KDE is running, the two systems are often difficult to tell apart.

BSD can also run most Linux programs with a compatibility layer subsystem, which is capable of running even proprietary Linux software. The BSDs each have a Linux-compatibility layer that is installed in a different manner depending on which operating system used.

For example, FreeBSD's Linux-compatibility layer can be installed by compiling FreeBSD with AAC_COMPAT_LINUX or loading already compiled FreeBSD systems with a Linux compatibility program: aac_linux.ko (Per BSD release engineer Scott Long in 2003) Linux cannot run BSD-specific software, although such software is uncommon. It is the compiled and executable program binaries that are somewhat different for each OS family. Generally, any program binary compiled from source code for BSD can also be compiled as a binary for Linux. However, compiling is a learned computer skill, and it doesn't always work as expected.

Lists, Descriptions, and Comparisons of BSD and Linux Distros

 * Berkeley Software Distribution: Open Source BSD Derivatives (BSD derivatives text descriptions)
 * List of Linux distributions (Linux distros text descriptions)
 * Comparison of Linux distributions (Linux distros comparison table)

Advocacy
Advocacy focuses on the differences among both OS families and brand-specific distributions. There are many similarities forgotten when families or specific OS's are contrasted.

Both BSD and Linux have dedicated user and developer communities. Every OS community makes a heavy investment of personal time, in distro implementing, and user learning to install, configure, and operate a branded OS. This focus of time and effort often leads to intense emotional investment. It sometimes results in overzealous advocacy leading to personal disputes that can harm OS communities. Emotional attachment to a consumer choice is familiar from branded merchandise loyalty toward designer clothing and automobiles. Rarely, extreme OS advocacy can take on an unhealthy similarity to religious persuasion, known to psychology as becoming a true believer. (See operating system advocacy).

Advocacy excess led to bad mass-media publicity for BSD and Linux in 2000 (see DeCSS). Bad publicity can politically assist commercial OS competitors, or digital rights management organizations, who are lobbying for laws to prevent the use of free software in government regulated hardware, such as cable and satellite TV decoders.

Hostile counter-advocacy is an important special case that will be sociologically and psychologically analyzed in its own section at the end of this article.

A positive value of rational, ethical, and consumer-oriented advocacy is that it can replace paid advertising that may not exist for free OS distributions.

The Linux Kernel and the GNU Utilities
-

Distro Installation Packaging Classification
Distribution installation packaging is sufficiently complex as to be shared by a number of distros. There are several standardly-named package systems:

BSD package systems
 * pkg/ports
 * pkgsrc

Linux package systems
 * apt
 * portage
 * yum
 * rpm


 * Although, apt and portage are original Linux package systems, both are being used in BSD environment.
 * The Gentoo Linux portage system has similar advantages to BSD ports, it being FreeBSD ports re-written in Python.

Hardware Issues

 * Commercial UNIX is usually designed for a specific hardware architecture intended for business enterprise applications. Redundancy, hot-swap/hot-plug (even some hot CPU swaps), and other technologies are utilized to minimize enterprise downtime. Commercial UNIX companies advertise five 9's reliability; 99.999% uptime, or about 15 minutes downtime per year. The BSD and Linux distros are working toward these goals, but specific hardware gives commercial UNIX a probably unbeatable reliability advantage.

Installation Issues
BSD and Linux installation experiences range from fairly easy to difficult, with occasional complete installation failures. New admin/users may not be aware that how the distro package installer works can have a significant effect on their satisfaction with choice of OS brand. Installations may need to be repeated. A difficult install tends to discourage learning the next phase of OS configuration and operation. A complete failure is usually due to choosing a distro with a small range of supported hardware. Admin/users should make an effort to learn the distro's likely supported hardware range before finalizing an OS brand name choice.

Configuration Issues
-

Administration and Distro Release issues
-

Operation Issues
When not using the graphic user interface (GUI), users enter commands on a command line presented by the shell, a command interpreter program. It is called a shell because in a flow chart diagram it surrounds the kernel. It interfaces data to and from the kernel for the user and other programs.

The traditional UNIX shell is sh, used both for scripts and for interactive use via the command line interface (CLI). It is considered to be somewhat lacking for interactive use, usually without working backspace and arrow keys, among other user's problems.

Linux uses bash, which, unlike csh, is an sh-compatible shell that has been enhanced with features for better interactive use. A single bash shell serves both interactive and scripting purposes well. MacOS X, despite being derived from BSD, has switched to using bash.

BSD historically added csh for interactive use, while keeping sh for scripting. csh is incompatible with sh, and csh lacks features needed for advanced scripting. Advanced users usually need to learn about both. Most BSD systems are configured with this combination of sh and csh, including FreeBSD, NetBSD, and DragonFlyBSD.

OpenBSD has chosen to use pdksh for as the default shell for all purposes, doing essentially what Linux and MacOS X have done with bash.

Generally, both sh and csh will be provided by default. It is possible to install modern shells like bash and pdksh on all of these systems, but this is a nuisance and may be difficult for a beginning user.

Application Issues
-

Developer Communities Organizational Styles
Generally, BSD is more centralized than Linux. The BSD OS (including Darwin and Tru64) is more properly compared to Linux OS, while the FreeBSD distribution is more properly compared to Slackware, Red Hat, SuSE, Debian, or Gentoo distributions.

Linux by itself can refer to the bare Linux kernel itself, or more commonly to any system based on that kernel. To function as an operating system, other utilities (file and system utilities, shells, etc. see the GNU project) are required. These other utilities are gathered from various sources and collected together with the kernel by various groups in distributions ("distros"). Kernel and system utilities are developed independently and merged together to form an operating system. This means that the Linux kernel has a version, and all the utilities in the operating system have their own versions unrelated to the kernel.

BSD presents as more centralized. The kernel and basic system utilities are developed, versioned, and distributed together. Other programs, such as X and web browsers, can be brought in from elsewhere, but the basic system comes from one source and is designed specifically for BSD. Being versioned together in the same Concurrent Versions System (CVS) tree affects interfaces between the parts. The parts need only to function in cooperation with other parts from the same supplier and time period, allowing nonportable assumptions to be made. The concept of a kernel version different from the rest of the system is not significant in BSD.

Linux is often claimed to be fragmented, yet the BSD OS family is also fragmented. There are quite a number of Linux distributions that all create their own patchwork of versions of all related components. While this sometimes applies to BSD (e.g., DragonFly BSD has multiple major versions in parallel use), the number of library version combinations and packaging decisions that one will encounter, is much lower if one does not consider NetBSD, OpenBSD, Darwin, Tru64, and others.

Centralized and distributed can each be better, and both models have their advocates; for example, focusing security or flexibility. BSD and Linux projects are not equal in size by number of contributors. A model that works for one doesn't necessarily work for the other.

BSD
The BSD licenses are designed to be completely usable, so that the code can be exploited to the fullest extent; conserving resources and relieving developers from reinventing the wheel by duplicating work which has already been completed and almost all code in a BSD operating system is licensed under one of the BSD-style licenses individually identified as the 2, 3, or 4-clause text.

This style of license puts very few restrictions on what can be done with code licensed under it. Depending on whether old, or new 1999+ version of the license ("BSD-old" / "4-clause BSD", or, "BSD-new" / "revised BSD" / "3-clause BSD"), the restrictions can be as simple as: Other possible restrictions include that:
 * preserving code source credits in the documentation,
 * keeping the existing license in place (prevents code adopters from claiming an original work), and
 * adopters cannot claim that the previous contributors endorse the adopter's new code derivative
 * adopters must list the copyright holder in any advertisements for derivatives
 * adopters cannot hold the contributors liable for any mistakes in the code.

After meeting those simple license restrictions, essentially anything else can be done with the code, including distributing closed-source modified versions. For example, Major Software and Apple have both used BSD code in their proprietary OS products, with Major Software choosing closed-source and Apple choosing open-source for its Mac OSX version of BSD.

However, BSD-style licenses with 2, 3, and 4-clause texts are still in use for various BSD distros and other free software components such as libraries. See BSD license:BSD-style licenses

FreeBSD uses a 2-clause license with an additional statement at the end that the views of contributors are not the official views of the FreeBSD Project.

Linux
The Linux kernel and many of the utilities commonly distributed with it are licensed under the GNU General Public License (GPL). The GPL's main restriction is that no additional restrictions may be added, ensuring that all future versions of the software will be free. This lets companies improve the software without fear that competitors will make it proprietary.

GPL v2 is the most common free software license in use today. It was designed specifically to morph all software into Free Software. GPL v2 does this by requiring that:
 * all works derived from GPL v2 licensed code must maintain the same restrictions on future derivatives of the code, which include,
 * releasing the source code to any parties who are supplied a binary compiled from the code,
 * supplying all parties who receive any GPL v2 code derivatives, with access to the code's companion license (such as by packing the GPL v2 license text in the same compressed archive with compiled binary and source code files),
 * not obfuscating released code
 * preventing any further restrictions to be placed on the GPL-licensed code - thus code licensed under the original BSD license cannot be licensed under the GPL v2

GPL v2 is intended to prevent the conversion of a free program into a proprietary competitor, so that all future GPL software will remain free, as conceptualized by the Free Software Foundation.

For discussion of the advocacy of one license over the other, see BSD and GPL licensing.

Market Economics of BSD and Linux Free OS's
All OS consumers benefit from free software even if they do not use it. The public advantage of having much software available under the BSD-style and Linux/GNU-GPL licenses is that free-market prices for proprietary licensed commercial software cannot rise without limit, because users can always turn to near public-domain free software. Yet because commercial software can be seductively innovated from free BSD licenses, GPL free software developers cannot fail to counter-innovate,* or users will abandon GPL free in favor of reasonably priced commercial software. Innovation failure is a classically observed problem of industrial socialism.

Thus a commercial vendor monopoly is avoided, and market prices are balanced by classic microeconomic laws of supply and demand that would fail if a monopoly prevailed. This particular balance is achieved due to free software's moderation of the unregulated free market, resulting in a mixed economy of privately socialized consumer demand and publicly capitalized commercial software corporations.

TCP/IP: The origin of Unix-like free software
Though the present free software socialization is private, the government socially capitalized free software through defense budget grants to ARPAnet, that paid for BSD's near universally used TCP/IP Networking Tape 2 software, first released circa 1990, that is usually known as Net/2.

TCP/IP was coded during the height of the cold war to supposedly help military computer network communications survive a nuclear war with the former Soviet Union. Nuclear war explosions with a total megatonage exceeding the threshold of nuclear winter, turned out to not be survivable by humans on the planet (see The Cold and the Dark by the late physicist Carl Sagan, et al.); but, TCP/IP networking was unintentionally an excellent taxpayer investment in software that couldn't be copyrighted or patented, and was therefore available free for every public use.

Is irrational "right to profit" trying to ban free software?
Because free software's moderation reduces the industrial profits of a software license monopoly, circa 2003-2004 news media reported that commercial software organizations (and probably digital rights management organizations) lobbied Congress for laws to prevent the use of free software in government regulated hardware, such as cable and satellite TV decoders. Achieving passage of such laws is the first step toward banning free software, and thus increasing commercial software monopoly license profits.

While their connection to lobbying for the free-software ban is not documented, nothing concerning this issue is generally believed to happen without Major Software's approval. E-list readers and reporters have previously reported a Major Software operative involved in trying to privatize Linux free software (see this well-known poster's offer to the linux.kernel mailing list attempting to buy a BSD-licensed copy of the Linux kernel worth over $600M for only $50,000, including judicial notice of evidence for his being an agent for Major Software.)

The philosophical basis claimed for passing laws banning free goods or services, is a revival of an old corporate claim of a "right to profit", which presumes that free goods and services should be banned because goods and services for sale cannot compete with free goods and services. This is not fundamentally true because of economically illogical passions such as brand names, personal vendor loyalties, and economic cooperation in coops; but, it is true that free goods and services reduce the market value of goods and services for sale. The idea of banning free goods and services is also impractical, since governments at all levels must give free education and other free things to children, disaster victims, the aged, and the poor. As close as has been achieved, some business-friendly states have antisocialist-economy laws banning state competition with private enterprise, which prevents coops from using the purchasing power of the state to lower the cost of commodities like generic pharmaceutical medicines or gasoline.

The basis of corporate shareholder stock purchase, is the risk of losing one's private capital, against the hoped reward of profit in some direct proportion to the shareholder's financial risk. Since economic risk cannot be legislated away, the economic result of all "right to profit" laws, is the transfer of some or all corporate business enterprise risk to taxpayers. Taxpayers then must pay if the corporation does not profit, yet receive nothing if the corporation does make a profit. At a minimum, taxpayers are providing corporations with enterprise risk insurance, but with no insurance premium paid back to the government treasury.

The ultimate result of an entrenched "right to profit" guaranteed by government, is that the corporation will, in all cases, receive the taxpayers' corporate welfare for doing, making, and selling nothing. In short, the economic notion of a "right to profit" is simply a disguised way of laying unlimited claim to the public treasury. That amazing claim is achievable in political practice, when very large campaign donations bypass taxpayer representation, sound fiscal policies, economic science, and the common sense of nearly all politicians of nearly all parties. The best analogy is that "right to profit" is a corporate fairy tale.

Major Software hints at software patents on Linux (and BSD)
Major Software's leadership has publicly suggested in outline form, that the next step against free software is enforcing software patents on routine computer operations. For example, using a mouse to click in a GUI window. Corporate leadership has mentioned Linux OS in other competitive contexts, so Linux is their obvious target. Major Software, being the holder of most such patents, could theoretically sue any Linux free software developer who wrote a program that used a mouse, and gave the patented program away without a charge in violation of patent licensing terms requiring a monetary fee exchange.

While abridging the human right of gift would seem to be a serious political rights violation, USA citizens are guaranteed considerably fewer Constitutional rights when the government is privatized, or not involved. Therefore it is quite realistic that Linux development could be halted by a USA Federal court order in the next 10 years. Furthermore, such an order would be binding on all countries that are signatories to patent treaties with the United States, and those treaties will be enforceable under the penalty provisions of the World Trade Organization (WTO).

Major Software could theoretically set the minimum prices of competing software, through the terms of a patent license, but in practice, they might get sued for engaging in a monopoly restraint of trade. Their second option is to deny patent licensing to any competitor, but that too could result in an anticompetitive practices lawsuit.

Major Software's third option is the best: demand a significantly hefty royalty on every copy of a Linux OS using their patents. Major Software could set this fee so that the Linux OS would sell, but not very well, and they could probably avoid a successful anticompetitive lawsuit. Having established patent control and even a piece of the Linux profit, Major Software would then engage all of their other previously known market practices to limit Linux to something like the sales of IBM OS/2 or BeOS, which sales were/are categorically also ran.

Major Software's history of co-opting open standards
Major Software has historically adopted open standards, gained installed base control of that open standards market, and then gradually changed the open standard by adding proprietary extensions, until all users are locked into the Major Software extensions that no one else is allow to copy. The final step in the cycle is to abandon that market in favor of a totally proprietary new system, leaving the installed base with no choice except migration to the new system.

With control of Linux's (and BSD's) software patents, Major Software could probably control most new Linux developments. Because they control the patents, they would always know what Linux developers were going to do. By foot dragging at critical contract signing times, they could make sure that any new Linux feature was always late to Major Software's critical corporate business market, and they would always have a campaign ready to suck the media oxygen away from whatever Linux was going to do to gain that business market.

When selecting between BSD and Linux *, it is only fair to point out that many influential software businesses have a strong interest in continued BSD development, including Apple Computer and its Mac OSX. Therefore BSD developers are less likely to be sued for software patent violations, than are Linux developers. Also the BSD license is less of a threat to software giants like Major Software and Nearly-as-large software. Unlike Linux developers, BSD developers generally dislike GUI's, and don't really want to compete the way Linux developers seem to want.

Centralized control of BSD is a disadvantage in an indirect takeover scenario. Among other things, the BSD community is presently small enough that Major Software could buy up the major BSD development talent, and so control the innovations that BSD produces. If BSD free releases fail to innovate, and Linux development is halted by patent violations, then users must to turn to Major Software and other commercial software monopolies at rising free-market prices.

Understanding Hostile Counter-Advocacy
The purpose of this section is not to stir up more trouble, but to help explain why some (but not all or even most) traditional BSD workers including development programmers and users, feel resentment toward other new members of the computing community. The purpose of doing this analysis is to help them feel better, because they may feel that no one understands their point of view, or appreciates the effort they have made for nearly 25 years to further the public domain with free software.

Hostile counter advocacy
Hostile counter advocacy occurs when users and user groups consistently engage in name-calling, discussion flame wars, and ad hominem personal attacks apparently based only on a preference of OS. All major OS user groups, Windows, Macs, BSD, and Linux user groups have engaged in hostile counter-advocacy (See DeCSS). But outsiders are frequently mystified by a casual observation that BSD user groups are particularly hostile toward Linux user groups, when outsiders observe little distinction between the two. Such hostility resembles the conflict of the Cherons, black-and-white aliens featured in a Star Trek (TOS) episode, "Let That Be Your Last Battlefield." The only difference between the two races of aliens was a mirror reversal of black side and white side.

Historic decline of elite craft workers
This type of hostility has reoccurred throughout industrial history, and is related to the Marxian class phenomenon known as proletarianisation. When an industrial craft is new, the relatively few early workers to master the craft become an elite workers group, and have a lot of influence and therefore power over the direction of craft development. For example, this was true of the early powered weaving loom craftspersons in England, who enjoyed considerably more privileges than other workers of their socioeconomic class, including the first adult education night classes. With the passage of time the craft matures, and it is taught to many other workers. As a result wages fall, the early workers' influence wanes, and they often express hostility toward the newer workers. These displaced feelings are psychologically projected onto other people, because there is no one else to blame for their personal and collective disappointment related to future shock.

Mass migrant discrimination
In a closely related social phenomenon, all waves of migrants are treated with varying degrees of contempt simply because they are newbies, who are vaguely perceived as a social threat because of their large numbers. Typical of this was the flaming of America On Line (AOL) ISP users when AOL finally allowed their users to connect to the open internet. Having been held back by regressive AOL system policies, they didn't know the things that other internet users had long taken for granted, such as the good manners of netiquette.

BSD worker marginalization
Dating the BSD craft from 4.2BSD UNIX in 1982, noncommercial Unix-like development was the exclusive province of BSD workers until the release of the Linux kernel in 1992. While BSD continued to quietly develop without public promotion, Linux became a well-publicized mass movement. By a decade later, BSD workers increasingly noticed that their labor-intensive volunteer efforts to produce free software were being marginalized by Linus Torvold's Linux kernel corunning with Richard Stallman's GNU ("GNU's Not UNIX") command utilities that BSD workers considered less well crafted than an equivalent BSD kernel with integrated BSD utilities.

CLI advocacy
BSD workers had always used a command line interface (CLI), in which a series of word-like commands are typed in following a prompt, which are usually executed by pressing the Enter key (formerly labeled the Return key). The CLI interface requires less program structure (overhead) than a graphic user interface (GUI), so programs execute faster. A CLI also offers better fine-tuning control of the OS configuration. BSD workers believe that a CLI can accomplish nearly every computing task, if only the user would read the documentation for each command known as man pages. However, Major Software had stopped writing official user manuals circa 1995, because they concluded that users would not read them.

GUI advocacy
On the other hand most new users have grown up while using a GUI in Macintosh and later Windows OS's. A GUI offers easier user control of the application program, for example, in moving blocks of text in a word processor. A word processor spends most of its time waiting for user input, so a faster OS is typically of less advantage in a productivity application (typically simple business software). A GUI is just plain easier to learn and use. In this regard most new users really are different than BSD workers.

CLI vs. GUI desktop interface symbolism
Therefore it wasn't surprising that marginalized BSD workers focused on the GUI as being a symbol of their decline in status. BSD workers were originally academics, and were always persons with high intelligence, prodigious memory, fast reading with comprehension ability, exceptional skills at mathematics and logic, physically dexterous touch typing, and capability of doing extremely difficult abstract work for many years running. Having these exceptional qualities, BSD workers considered themselves an elite group, and rightly so.

Perceived inferiority of GUI users
By inverse logic, any user who wanted a GUI, was not like BSD workers. By inverse logical stereotyped extension, GUI users were collectively not smart, had a weak memory, couldn't read well, couldn't type well, and were more or less lazy. That a GUI is easier, is an advantage that does not necessarily impress traditional BSD workers. BSD workers tend to have an attitude attributed to historic Calvinism religion that a desire (and ability) to do things the harder way is a sign of moral superiority. This is one example of why OS advocacy sometimes resembles religious proselytization.

Identifying Linux with a GUI
New users typically request that populist (opposite of elite) Linux developers provide a Windows and Mac-like GUI desktop interface. This GUI desktop is usually the X Window System and can be compiled as binaries for use with all BSD and Linux OS's. The two most common developer implementations of X Windows are GNOME and KDE. BSD workers call the X Window System an optional application program, and not part of the BSD or Linux OS. New users perceive X Windows from a Major Software Windows and Apple Macintosh perspective, in that those OS's almost don't exist without the GUI. Therefore new users assume that X Windows is by necessity a part of Linux, and should be a part of BSD. Linux user groups and developers accept this, which leads directly into competition with Windows, and therefore conflict with Major Software. BSD workers typically don't agree with new users perceptions that X Windows should be a part of BSD, which helps them avoid conflict with Major Software. They will closely watch what Major Software does to Linux developers.

Identifying BSD with a GUI
Some BSD developers have become populist and are packaging BSD with X Windows in a default installation, for example, DesktopBSD. DesktopBSD is no different than FreeBSD running a KDE desktop application, but the user can do a reinstall with less configuration work. There is also a perception advantage. The new user tells others that DesktopBSD installs like an OS is "supposed to". Traditional BSD workers don't think it's "supposed to" install this way, but with waves of new users, what they think is increasingly marginalized, and some of them are increasingly resentful because of it.

Loss of BSD workers' abstract language
Language abstractions are a major part of group identity and elite privilege. When large numbers of migrating users begin to redefine concepts, such as what Linux or BSD "is" (e.g., must install with a desktop), then formerly elite BSD workers experience a further loss of status and privileges to name and define OS or application abstractions. They find that they can't even discuss issues in a public newsgroup without frequent off topic debates about what BSD, Linux, and other abstract computing concepts mean. Because identity, investment of effort, and subscription to a cause is closely associated with language, this can result in feelings of losing one's personal identity, feelings of having wasted large portions of one's life, feelings of having engaged in a lost cause, and most importantly, feelings of being unappreciated or even worthlessness. This is a serious challenge to good psychological health, and defensive reactions are psychologically normal, though certainly not good social politics.

Diversity of BSD workers reactions to diminished elite status
Some traditional BSD workers resentment of their steadily eroding status results in defensive hostile counter-advocacy toward GUI users generally, and Linux users specifically. This behavior tends to start feuds, since other users can't understand what some traditional BSD workers or users are defending. Obviously not every traditional BSD worker reacts with hostility to a loss of former status. Some accept that the CLI BSD period of history is fading and move on to other interests. Others accept the changes in language, continue to focus on BSD kernel development, and ignore what end users do with GUI. Still others embrace populist change and develop what new users want from them, while continuing to develop what they believe to be the technically superior BSD OS. Some may cynically expect Major Software to crush Linux, and wait for BSD's opportunity to pick up the pieces. Even if Major Software does not crush Linux, BSD is still likely to become Major Software's official Unix-like OS. When that happens BSD will look exactly like Linux, desktop and all, but the BSD workers will say, it's still better crafted on the inside.