May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Solaris vs. Linux: Framework for the Comparison

by Dr Nikolai Bezroukov


Prev Contents Next

8. Using Solaris-Linux enterprise mix as the least toxic Unix mix available

The main purpose of the paper is to structure large and complex topic "Solaris vs. linux" into key subtopics, and suggest that despite being close competitors Solaris and Linux has a lot in common and are least toxic enterprise mix of two flavors of Unix currently available.

The comparison I made (with all its shortcomings) suggests that naive dreams of linux replacing all Solaris systems or vise versa should be dropped and both linux and Solaris should be considered as not only competing but also complementary OSes.   Supremacist view of the part of linux developers crowd should be abolished as naive and unrealistic: it is clear that in some areas linux never was and will never be superior to Solaris (and, for a change, to AIX and HP-UX). This is one of the most interesting observations that unbiased reader can get from reading the paper. Linux strongest point is commodization of good features existing in other flavors of Unix and in this sense it is a pretty backward, reactionary OS ;-). Paradoxically but our exploration of Solaris history suggest that it  were the commercial developers who had driven the Unix technology forward for the last 15 years.

In the process of writing the paper the author came to painful understanding of a second important point: the level of complexity of modern OSes far exceeds human capabilities.  It is very easy to criticize the paper like this accusing the author in incompetence and sadly enough many such points will be true. In a sense complexity of current OSes really shows the limitations of human abilities.

That's probably why we often love a particular OS and so passionately defend it. It happens just because of the huge investment we made as well as because if you know OS better it will be more stable and reliable in a particular environment. In a way, due to this complexity, differences in sysadmin qualification and historic preferences supersede differences in OSes "native" stability and maintainability.

I never had any illusions as for my knowledge of linux, but what I realized during writing of the paper is that my knowledge of Solaris leaves much to be desired too.  I also realized that while they are different in more ways that I thought before starting writing of this paper they are still two closest version of Unix out of any pair retrieved from the linux+solaris+AIX+HP-UX poll . I am really convinced that that difficulties in managing two of them and differences between Solaris and Linux are far less then any other combination of existing enterprise-ready Unix flavors. They tend to complement one another in more ways then any other pairs with possible exception of FreeBSD and Solaris.

At the same time there are obvious differences and it is not that easy to became equally proficient in tow OSes. In no way the author can claims that he completely understands the issues discussed about the two OSes described: both are extremely large and complex products and the author experience with both is limited to several highly specialized areas.  But at the same time they are the only that can be used on the same hardware and while linux is dominating X86 hardware installations Solaris on X86 is an interesting option for more critical part of the server park. Especially for the organizations where Solaris represents the dominant part of RISC servers park. 

But as always in system administration the devil is in details. Both Solaris and Red Hat and Red Hat and Suse are very different. But I would like to stress it again that they are less different then any other possible combination of Unixes in large enterprise environment and when you need to take sides in order not to get into "three or more flavors of Unix in a single organization" trap you should be aware about that.  I can easily see large enterprise datacenters converted rather painlessly to Solaris-linux enterprise Unix mix. Of course that leaves out AIX and HP-UX each of which has its own strong points and the army of devoted administrators.  But if Solaris is present, then most often either AIX and HP-UX are present too and the classic situation aptly named "Bolivar cannot carry double" in already mentioned famous (actually mainly among Eastern Europeans ;-)  O. Henry story  "The Roads We Take"  arises in all its dark glory. 

I would like also to stress that the acquisition of top level administration skills is a long, expensive process that with the current level of complexity of OSes takes probably not two-three like before but five-six years even for the most capable specialists . That means that such skills represent an important part of the company intellectual capital. And this capital should be treated with care without abrupt and unjustified by real business needs disruptions in cases were such disruptions can be avoided. To quote  Linux Torvalds, switching from administering one OS to another  is not unlike “performing brain surgery on yourself”.

The complexity of modern OSes had risen to the level when it is almost beyond the capability of single, even very intelligent, person to understand them. That means that top level admin skills can be acquired only during the long time and they represent important part of the company intellectual capital. To quote  Linux Torvalds, switching from administering one OS to another is not unlike “performing brain surgery on yourself”.

High cost of adding a new flavor of the OS to the large enterprise OS mix

The most important finding of the paper is that adding a new flavor of Unix into preexisting enterprise mix is a complex operation that has side effects.  If Solaris is already present or dominant in the infrastructure preserving  Solaris and linux is safer then preserving AIX or HP-UX.  And some flavors of Unix need to go if you add linux (cuckoo effect of linux). Otherwise you face the situation with the increased number of Unix flavors used and as we argued above this increase badly affect welfare of system administrators, whose human limits due to the complexity of environment usually are around two OSes and in end of the day they determine the actual costs of the Unix infrastructure.

Often "over-proliferation" of Unix flavors necessitates either split of Unix administrators group into subgroups with each responsible for a particular couple of flavors of Unix (with additional overhead, red tape, and/or potential infighting inherent is such split).  So in a sense in order to succeed the introduction of linux should always be a replacement of one of pre-exiting flavors of Unix and in no way it should just an additional addition to the enterprise Unix mix. No matter how many  simplistic presentation and naive spreadsheets suggest that just an introduction of linux lead to the savings.  those fake saving fail to materialize and quite easily are converted into their opposite.  

Side effects and complexity of the task of adding yet another flavor on Unix in a large enterprise environment should not be underestimated.  Qualification of sysadmins and of paramount importance for the success of any such, even completely justified, move. Adding linux should mean replacement of one of existing flavors of enterprise Unixes, never a step in proliferation of Unix flavors used

Issues here are complex and negative effects of "over-proliferation" can be profound.  Sysadmins need to know the system in-depth to ensure reliable performance (and other things equal that's more difficult to ensure for linux then for other enterprise Unix flavors)  and with the current complexity of operating systems even with sufficient training that goal can be achieved only for one or at most two flavors of Unix. Of course much depends on the quality of sysadmins. Like car jocks used to say "there is no replacement for displacement" ;-)

Moreover, if an organization has no high quality specialists it becomes a hostage to the expensive and sometimes unscrupulous consultants from various "professional services" organizations and that tends to drive costs higher and quality of service lower.  Unless Solaris-Linux mix is used introduction of linux might logically lead to costs overruns.  The relationship between the age of the OS and the vitality of the development team.

While choice is painful in large enterprise environment which introduces linux it is important to decide which of exiting flavors of Unix need to go and from two evils to select lesser.

That means that adding Linux to exiting framework also necessitates the decision of which existing flavors of unix to  retire. In my opinion Solaris should stay. 

Linux is an old OS which has its own development problems and which needs to learn to co-exist with existing Unixes
 and first of all with Solaris

"The guard is tired."

Famous quote from the history of the USSR
(attributed to the anarchist sailor Zheleznyakov)

An important impression the author got from writing this paper is that in no way Linux will manage to replace enterprise flavors of Unix. It needs to learn to coexist with them. While distributed development framework is the essence of open source and provides the strength of Linux kernel development the Linux guard is tired and disillusioned.  The dreams of "Cathedral and Bazaar" dissipated on the first contact with the reality. That means that the development more and more converges into traditional "industrial cooperative" framework. It is driven not by volunteers (to call Linus Torvalds a volunteer is some respect a cruel joke -- he is more like a prisoner of his own ambitions and social status of "father of linux kernel") but by salaried employees who are at the same time prisoners of the particular social movement. I wonder how many of the them in the depth of their hard hate "open source crowd". Key developers are dispersed in several organizations that finance this cooperative (instead of traditional team within a single organization, most often in a single location) which make cooperation more challenging, more difficult and more prone to conflicts.

Moreover the linux development is understaffed and overstretched with extremely ambitious and fuzzy goal of "world domination": creating the best OS on the planet for everything from toaster to mainframe. If we assume that kernel and major subsystems development are conducted by a distributed industrial cooperative with costs shared among several large players, then problems facing linux become more clear: as in any cooperative contributions are dependent on the good will and financial health of participants, each of which tends to be slightly suspicious that other do not provide a fair share.  

Also fifteen years of development are fifteen years of hard work and it is natural that the initial enthusiasm vanished and sometimes changed into disappointment (or even resentment) and that the focus for even the most devoted members of the core Linux kernel development group including Linus Torvalds himself started shifting and conceptual integrity of the product suffered as a result. Both decisions made and implementations adopted are not as sharp as they used to be at the beginning. Partially because the size of codebase becomes prohibitive and while any change/improvement is possible nothing is simple anymore.  Like Larry Wall aptly noted about Perl 5 implementation, working with such a monstrous codebase simply stopped to be fun (that's why he decided to launch an ambitious project to create Perl 6 starting the implementation from scratch).  Working with such huge and complex codebase became a hard, exhausting work no matter what salary you get.  Huge size of the codebase also tends to block the infusion of new talent.

As I mentioned before, at the end of day it became evident to everybody that open source does not have a monopoly neither on technical talent, nor on innovative ideas, not on the quality of implementation. Sole level of specialization of Linux is quite welcomes. It simply cannot be "all things for all people".

First of all Linux might never be able to reach the stability of Solaris, AIX or HP-UX. Also, while open source in general and linux in particular had its share of innovative ideas (especially in the area of scripting languages were open source dominates) many important innovations for Unix came from traditional channels of innovation. For example, neither VNC, not ZFS, nor Dtrace were products of open source development.  The same is true for VMware, Xen and AIX Lpars which legitimized the virtual machine concept. To add insult to injury for open source zealots Xen development was partially financed by Microsoft Research and Microsoft implementation of Python (IronPython) runs faster then its open source counterpart. All those examples suggest that there is nothing that prevents other OSes to surpass linux as the best choice for particular application areas and that competitive threat of linux should not be overestimated. The dream of world domination turned into pipe dream, and if so the question arise are all those personal scarifies endured by key developers outside "linux money crowd" worth the result ? Would they be better using their talent in concentrating of clearly defined areas instead of spreading too thin ? Also it might be better for at least some of then to join more conventional organizations like commercial software startups and get some real money in return for 80 working hours weeks they endured...     

Even the idea of creation of universal high quality kernel by geographically dispersed, Internet connected team of high quality specialists in not without problems. As Napoleon said after the Battle of the Sands that two Mameluke usually could defeat five French solders, but 100 French usually could defeat 500 Mamelukes (or something to that effect). His point was that proper organization, talented management  and discipline helps to win battles even if individuals involved on the other side are more motivated, better trained and equipped,  but less well organized and suffer from the lack of discipline. That does not mean that the corporate environment is a paradise, it has its own well-known problems, but still this quote has some relevance to open source development of complex products like Unix kernel  [Bezroukov1999a, Bezroukov1999b]. Also mail list as the main methods of communication proved to be inferior to a real room with a blackboard were two or more developers can freely discuss their ideas or even to a traditional corporate teleconference. It provokes too much ego-related infighting and that makes it difficult to separate the wheat from the chaff.  I like better the “virtual water cooler” concept using IRC that Canonical seem to push, but it is not without problems too. Virtual is not always better then the real thing. In open source literature similar kind of problems are usually discussed under the banner of "difficulties of herding cats" ;-). See for example How to Herd Cats and Influence People - 2007.  As Tom Hanrahan, OLSL head of Linux engineering noted [Hanrahan2004]:

As far as how you manage it, you do have to think more in terms of how you influence the direction things are going rather than dictating how things are going. I guess that's the sense you have when you talk about herding cats or having organized chaos.

Also the age of the OS does matter. Historically no OS managed to grab significant additional market share after more then ten years of development as at this point novelty of OS, if any, starts to disappear and the focus automatically switches from occupying new territories to defending the currently occupied turf and providing compatibility with previous generations of the OS. There can be exclusions, but still this rule usually holds. And success brings its own problems: not only the compatibility with previous versions might soon become a huge problem for linux (the first profound effects of which probably might first be visible in the slow pace of switch from RHEL 4 to RHEL 5).  More dangerous problem is that focus shifts from principal things to superficial polish and system became heavy from bells and whistles (that's another way to note the loss of conceptual integrity). In a way the problems with new versions of linux enterprise distributions are very similar to those that Microsoft faces with the development of Windows: accumulation of fat due to the introduction of new unnecessary features and bell and whistles like innumerous generations of more and more cute animated icons (note the waist of efforts and problems for users introduced by changes on the icons and other "balkanization of interface" type of improvements in Office 2003) and the problem of motivating users to move to the new version (for example from Windows 2003 server to the forthcoming Windows Vista server). In large enterprise environment when new version does not provide compelling advantages over the old many people feel that upgrade does not worth it and until support of the older version lasts will stick to the old version. 

Moreover, after ten years of development any OS can be legitimately called "a legacy OS" as warts and driven by compatibility requirements compromises start to affect the architectural integrity. In general OSes behave not unlike humans: any chronic health problem that can be attributed to architectural (or in case of humans genetic) deficiencies become more pronounced with the age. 

In short linux is not a magic bullet and in the large enterprise environment the OS has a lot of issues and first of all in the area of stability as well as related and even more important problem of conceptual integrity. So it will co-exist with other Unixes and never will be able to replace all existing commercial flavors of Unix.  And some level of specialization is already occurring with Linux mainly used in areas were issues of stability can be resolved by introducing the redundancy like in internet-facing Web servers.

Therefore the claim that linux is a revolutionary OS was OK for 1992-1998. First versions on linux starting from 0.1 were really the smallest "semi-POSIX compatible" OSes known, the tiny and fast OSes capable of running GNU applications on regular 386 PCs using minimum of resources (4M or even 2M of RAM was OK).  Also a fit of reengineering a kernel, capable of running most GNU applications from published specifications, the book Design of the Unix Operating System by Marice J. Bach and series of  William and Lynne Jolitz's papers in Dr. Dobbs Journal  in one year by a student should also be commended although it is far from being revolutionary in a pure technical sense and looks more like a Guinness record.

But this claim is largely unsubstantiated in year 2006 and later. Linux now should be properly called "legacy OS" belonging to the same category as Solaris and Windows.  Actually Windows NT  is an OS that is younger then Linux as it was first released in 1993 and was available for Intel IA-32, MIPS, Alpha and PowerPC  architectures (actually Windows NT 3.51 was ported to SPARC too, but the product was never sold). 

Of course none of those operating systems stands still and there is not much left in Linux kernel 2.6 from versions 1.x, or 2.0. But the underling framework of ideas remains intact and the same is true for Solaris.  Both represent Unix Renaissance, both are true descendants of the same OS paradigm created in AT&T many years ago, which in turn was inspired by ideas pioneered by Fernando Corbato and which were acquired by AT&T researchers during their participation in Multics project in late 60th of the last century (AT&T withdraw from the Multics project in 1969; A year later DEC introduced the first PDP-11 (PDP 11/20) and that was the computer architecture on which Unix matured.  BTW the PDP-11 was a phenomenal success very similar to PCs success decade later and that definitely contributed to Unix success similar to Intel CPUs successes huge contribution to linux popularity: rising tide lifts all boats. 

Also due to the age of OS, Linux kernel development now faces the problem of change of the guard as the "regime" of Linus "kernel" Torvalds cannot last forever and after more then fifteen years of development any OS developer starts losing edge. Kernel development requires phenomenal sacrifices in terms of personal time and commitment and for the old guard that also by-and-large gone. Now with each new version of kernel they are probably thinking "Do I want to push this big rock up a hill again?"  It might be that Linus Torvalds is closer to the status of another retired dot-com millionaire with his own small park of Mercedeses and yacht that most people suspect.  Solaris is past this cycle as Bill Joy, who in his Berkeley years  single-handedly  "outcoded" the entire AT&T (as Kirk McKusick used to say  "BSD was Bill Joy, initially"), left Sun in 2003, almost five years ago [Ricciuti2003].  BTW even several of Bill Joy early software utilities created for BSD project like C-shell and vi editor survived in modified forms till those days. Ironically, the main contribution that is usually used as linux claim to fame (at least according to Raymondism),  creating a model for open-source software development, was actually done by BSD team at Berkeley with Bill Joy as the major contributor.

As other vendors now invest serious efforts on grabbing low end Intel-based servers market share linux might never grow significantly beyond the current share, leaving Red Hat with a cash flow problem that might negatively influence the quality of support of respective distribution.  Fallout from the Microsoft-Novell pact recently led to layoffs in OSDL (nine out of 28 staffers), the only cooperative venture between large vendors devoted to Linux kernel architecture development.  CEO Stuart Cohen  resigned saving OSDL approximately half-million dollars in salary. Hiring lawyers instead of technical specialists by OSDL made future direction of this cooperative venture between Intel, IBM, HP  (and several minor players) even more fuzzy. With the annual budget of only eight million dollars OSDL cannot sit between two chairs. Torvalds is still there, but  strategic focus of OSDL is under question. It may be re-tuned for legal combat instead of Linux kernel architecture development. On the other hand Oracle's frontal attack on Red Hat by hijacking the support revenue might be just the first sign of future troubles for "pure play" open source software vendors.

Advantages of  Solaris on X84-64 for large enterprise environment

There are several often overlooked positive features of Solaris as an alternative to Linux on x86-64 hardware in large enterprise environment:

Disadvantages of Solaris

Like any OS Solaris is not ideal and has its own set of shortcomings. Some are serious, some are not, but that measn that linux can complement Solaris in large eneterprise enviroment and sucessfully comete with it in several areas where such shortcomings matter most. Among those that matter for large enterprise environment I would like to mention

While each of listed advantages and disadvantages is important, still those are details and they cannot change the key  message of the paper:  TCO reduction in the large enterprise environment is not directly connected with the quality of the OS or its real or imaginable advantages over existing Unixes be it  AIX, HP-UX, linux or Solaris.  Side effects and complexity of the task of adding yet another flavor on Unix in a large enterprise environment should not be underestimated.

Possible "convergence" moves on the part of Solaris

Solaris team already recognased that is needs to "play nice" in mixes enveronment with linux as one of the most important mamebers. But there should be some additional steps. There is no reason why Sun can't use Debian interface and applications with Solaris as the kernel.

Please note that as of March 2007, Sun stared addressing several of those due to recent hiring of one of Debian founders Ian Murdock[Farber&Dignan2007]. As Ian wrote in his blog:

"I'll be advocating that Solaris needs to close the usability gap with Linux to be competitive; that while as I believe Solaris needs to change in some ways, I also believe deeply in the importance of backward compatibility; and that even with Solaris front and center, I'm pretty strongly of the opinion that Linux needs to play a clearer role in the platform strategy."

Dangers of proliferation of Unix flavors in large enterprise environment

Let's reiterate the most important part  of argumentation in this part of the paper. Proliferation of Unix flavors  negatively affect the benefits of introducing new Unix flavor into the large enterprise environment:

  1. The side effects of adding each additional Unix flavor deployment on a number of supported flavors of Unix (Unix flavors proliferation) often nullify real or imaginable benefits from the adoption. Excessive variety of Unixes is a chronic and costly disease that many large enterprises suffer from.  The articles stresses that the importance of this issue simply can't be overestimated: the level of "Unix diversity", not the set of flavors of Unix used is the dominant factor in determining the TCO of Unix infrastructure for large enterprise environments. Important advantage of Solaris is that it does not have problems connected with Linux fragmentation into several different distributions with at least two major enterprise-class distributions (Red Hat and Suse with the latter recently enjoying a huge boost due to its pack with Microsoft and which due to this pack can eventually displace Red Hat from the top stop).  

  2. The frequency of patching also has disproportional effect on TCO of a particular OS in large organization environment. It also has great influence on the security of the infrastructure. Other things equal large enterprises benefit from an OS that can be used with the less frequent patch cycle.  Linux (at least as of early 2006) requires more frequent patching then any other major enterprise-ready flavor of Unix (AIX, HP-UX and Solaris). The paper point out that if  linux patch cycle is artificially made equal to patch cycle of major enterprise OSes the level of security can deteriorate. The author argues that the length of patch cycle for linux should be probably equal to length of patch cycle for Microsoft OSes (typically one month). This fact significantly lessens that attractiveness of linux for large enterprise environment but can be mitigated by running firewall (which is well integrated into RH 4), as well as running linux under VMware or (with the forthcoming integration of XEN) in separate specialized "minimal" linux images created for a each major application (similar to Solaris zones partitioning) but both solutions increase demand for already highly stretched administrator workforce.

Due to those two issues Solaris 10 on Opteron (and in 2008 probably on Intel Duo/Quattro CPUs)  represents a viable alternative to deployment of Linux in any large enterprise which already has substantial Solaris presence and that wants to reduce the cost of hardware due to better cost/performance ratio of Opteron CPUs (and later in 2007 Intel Duo and Quattro CPUs as Sun signed pact with Intel to support this line of CPU too) and commodity pricing for Intel-compatible hardware. Availability of Solaris for enterprise customers is not limited to Sun hardware:  HP supports Solaris on many its Opteron-based servers along with linux.

From purely technical standpoint Solaris is a quality OS and in many technical areas is equal or superior to linux. The open source model that was adopted for the Solaris OS ensures that this standard will be maintained. Most enterprise applications that are available on linux are also available on the Solaris. Also Sun also has an extremely good and largely deserved reputation in terms of quality of support, training and certification. In those areas it is superior to offerings from Novell or Red Hat although Red Hat has an advantage of keeping training "in-house" while Sun outsourced it and that negatively affects quality and Novell in the most democratic as for training and certification options (Red Hat has very expensive as for open source OS training  and certification options even if we are talking about large enterprise financial capabilities).

If you're currently using linux in large enterprise environment as Web front end, it make sense taking a look at Solaris, as a more scalable alternative slightly biased toward higher end hardware. Security wise Solaris has a substantial lead over any Linux distribution and no amount of hardening can compensate for absence of  RBAC implementation and zones in current linux distributions.  That fact (combined with the necessity of more frequent patching for linux) means that maintaining the same level security on linux will always be more expensive for large enterprises. Of course other factors, like the qualification of staff can offset this disadvantage.

All-in-all Solaris is powerful, stable, conformant to standards OS that can run many open source applications as well as Linux and some (mainly multithreaded applications) better then Linux. Like in the cases of Red Hat and Suse, the cost of support is extra, but it is more reasonably priced. Security patches are free which makes Solaris similar to Windows (the latter paradoxically is very competitive with Linux if we are limiting ourselves to enterprise distributions with paid annual support requirements such as Red Hat and Suse).

While many of open source enthusiasts would prefer linux for everything they do, nobody can deny that "stability is a sign of professionalism" and I would add the compatibility is an important sign of professionalism too.  This paper suggest that Solaris as a brand did quite a lot of good and introduced many important innovation in Unix. From technical standpoint currently Solaris 10 is the leader among Unix flavors in large enterprise space and while you don't have to love the leader (or respect technical quality; this is unfashionable thing in modern IT ;-), some experimentation and acquiring the working knowledge of the system would not hurt even for the most avid linux supporters. They might be surprised what they will find...

Prev Contents Next



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created Jan 2, 2005.  Last modified: March 12, 2019