|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
Nikolai Bezroukov. Portraits of Open Source Pioneers
For readers with high sensitivity to grammar errors access to this page is not recommended :-)
Despite his initial success with GNU tools and, especially with GNU compiler RMS failed with development of the a Unix compatible GNU kernel. That might be because RMS was a newcomer to the Unix field at the early days of GNU project and his decision to concentrate efforts on compliers and utilities was a wise one. But when it come to the task of creating of the kernel he has his hands partially tied by the necessity to maintain already developed products as well as the lack of understanding of the OS design issues (which arguably made him a perfect candidate for the creation of the kernel, putting him into the same camp as Linus Torvalds).
But unlike Linus Torvalds vision, his vision of the GNU kernel development was more modest: not to reimplement using key ideas of BSD kernel as a blueprint, but to reuse an existing prototype. Unfortunately he had chosen Mach micro kernel as a prototype.
While technically fashionable and not without tech merits this RMS decision proved to be a very costly political mistake due to the complexity that did not well suit the open/free source software development.
Greed was probably also a factor. RMS wanted to hoard as much software as he can reach. GROKLAW has an interesting quote belonging to Thomas Bushnell who was responsible for the kernel efforts about the decision to go with Mach:
RMS was a very strong believer -- wrongly, I think -- in a very greedy-algorithm approach to code reuse issues. My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today.
RMS wanted to work together with people from Berkeley on such an effort. Some of them were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.
So RMS said to himself, "Mach is a working kernel, 4.4-Lite is only partial, we will go with Mach." It was a decision which I strongly opposed. But ultimately it was not my decision to make, and I made the best go I could at working with Mach and doing something new from that standpoint.
This was all way before Linux; we're talking 1991 or so.
Although Mach (which oversimplified is not unlike PC BIOS, subsystem providing core Unix kernel services to the rest of the OS kernel) is a simple and attractive concept, in reality it failed to provide compelling advantages over the conventional (and more simple) monolithic operating system kernel. There were several successful commercial implementations (including IBM AIX and Apple OS X).
But the key deficiency was that micro-kernels are considerably larger and slower then monolithic kernels partially because of the complications of a modern virtual memory system (copy-on-write facility) as well as the need to support many different hardware devices and complex optimizations in communication facilities, all of which have been handled inside most micro-kernels. As such they are more difficult to implement as an open source project.
Development of Mach showed that performance problems forced services originally implemented on top of a micro-kernel back into the kernel, further increasing its size -- inter-machine network server has been added back into some versions of Mach. Micro-kernels do not support domain-specific resource allocation policies any better than monolithic kernels and this is an increasingly important issue with sophisticated applications and application systems. For example the standard page-replacement policies of UNIX-like operating systems perform poorly for applications with sequential access to data -- and that is too important class of applications to ignore.
Placement of conventional operating system kernel services in a micro-kernel-based server does not generally give the applications any additional control as the server is a fixed and protected system service. Adding resource management policies to the micro-kernel fails to achieve the efficiency that application-specific knowledge allows and increases the kernel size and complexity. Finally, size of the micro kernel is substantially bigger due to exception-handling mechanisms that are needed to secure the separation of the micro kernel from other system services. This problem with size was about important disadvantage due to severe constrain on resources and requirements for coordination of efforts.
Orientation on micro kernel delayed the project for at least two years and Linus Torvalds used this opportunity to provide an alternative to Hurd Linux kernel. Version 0.2 of Hurd was released on June 12, 1997. Losing four years to Linux was essentially a death sentence for the project because when Hurd beta version was available Linux was in v.2.0 and the game was over. Hurd lost on the user front, not on the technical front. Here Linus Torvalds proved to be a much better strategist than Stallman and the success make FSF essentially redundant as its goal of creating a free OS was formally achieved by Linux. For some time Stallman fought a bitter "renaming battle" (first he suggested to change name to Lignus and then to GNU/Linux; both suggestions were rejected by Torvalds.)
But later those abilities played slightly against Linus as he accepted a position (with half-joke half-serious rumors that his position is called the director of marketing ;-) in Transmeta -- a very secretive startup that develops VLIW (very long instruction word) CPUs. Funded by some heavy-hitting investors, including Microsoft co-founder Paul Allen and billionaire investor George Soros, Transmeta was founded in 1995 by Ditzel, who was a key architect of Sun Microsystems' SPARC processor family and before that worked at Bell Laboratories. This sitting between two chairs (tricky position, about which, in order to preserve face, Linus claimed he has no problems at all) created uneasy feeling about Linux as a controversial movement and helped Stallman to underscore the importance of GNU project and FSF (The obsessively secretive Transmeta demanded that employees reveal no more than four pieces of information to anyone: the name of the company, its location in Santa Clara, that its CEO was David Dritzel, and that Linus Torvalds worked for the company.). Transmeta's culture of secrecy was exactly opposite to OSS culture and it may have been less about protecting revolutionary technology than about concealing the chip's not-so-stellar performance history (from Technology News from Wired News):
Speaking on condition of strict anonymity, engineers with a major computer manufacturer said that after years of painstaking design work, the earliest Transmeta chips were a big performance disappointment. The engineers would neither confirm nor deny their company's plans to build Crusoe devices.
"They were dogs," said a Transmeta engineer, who also spoke on condition of anonymity. "We were in trouble."
However, the engineers were confident the company would have no trouble turning a profit now that the design problems had been ironed out and the chips were poised for release.
Subsequent Linux IPO gold rush when Red Hat and VA Linux got multibillion initial valuations increased suspicions that something is rotten in the Dutch kingdom.
Paradoxically the commercialization of the Linux movement and the crowd of newly minted millionaires (including Linus Torvalds himself) and (for a short period) even paper billionaires around Linux startups created a second chance both for GNU project and FSF.
For example gave a second chance for Hurd -- Debian team was interested in continuing work on Hurd in parallel with Linux. But the availability of resources was not there and nothing important materialized from Debian efforts. Moreover Debian project itself suffered severe setback by being over marketed and overshadowed by Ubuntu team which wisely preserved compatibility of packages to be able to reuse Debian huge package repository.
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard 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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How 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-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and 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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Created May 1, 1996; Last modified: September 12, 2017