Nikolai Bezroukov. Portraits of Open Source Pioneers

For readers with high sensitivity to grammar errors access to this page is not recommended :-)

Chapter 5: Alan Cox and the Art of Making Beta Code Work

(production kernel hard worker in the shadow of benevolent dictator)

version 0.34

• Introduction
   

• Biography Notes
   

• References
   

• Interviews and papers
   

Introduction

Naive (Raymondist) version of Linux history is that Linux kernel was created by Linus Torvalds as the superstar programmer. But in reality from the very beginning several important kernel subsystems were developed independently. One of such subsystems was network stack. Here the heroes were definitely Fred van Kempen  and then a programmer from Great Britain Alan Cox.  Alan Cox also proved to be a master maintainer of production versions of Linux kernels, the quality that permitted Red Hat to survive in a pretty difficult and competitive environment. Please read the interview section of this chapter. It can tell you quite a lot about events that comprises the actual history development of the Linux kernel.

Biography Notes

Alan Cox (born 1968) was a very active Linux kernel developer, No.2 in the Linux world for the most important period of Linux history (1991-2002). Before becoming a maintainer of the production version of the kernel he was the maintainer of network stack, one of the most critical parts of the Linux kernel (see Mindcraft Fiasco for more details). And his interviews are much more interesting that interviews of Linus Torvalds, so as for the quality (but nor quantity) of the interviews he is probably No.1  ;-).  Again I strongly recommend you to read them all. His papers are pretty interesting as well. One of them --  Cathedrals, Bazaars and the Town Council  -- became a classic.

His first computer was The ZX spectrum 128. He wrote a game called Blizzard Pass. It was released with a Spectrum 128K launch pack, then by Tynesoft as part of a two game pair. The rights to the Spectrum 128K version and the game interpreter it uses are still owned by Adventuresoft UK and/or Tynesoft.

He has a BS in Computer Science from the University College of Wales, Swansea. In one of his interviews (to Jeremy Andrews) he describes his early years in the following way:

...born (that bit is required anyway), school, chickenpox, German measles, mumps, lessons and somewhere down the line computers thanks to a couple of teachers interested in computing who gave up their own lunchtimes one evening a week to teach pupils who were interested. At the time the school had 3 computers and you'd get maybe 15 or 20 minute sessions, but that was way more than most. Somehow computing just soaked in, so by the time I officially did computing at school I was the owner of a ZX81 (first real mass market cheap UK computer) and already teaching the teachers.

I did the end of school exam ('O' level to UK people) in 30 minutes for a 3 hour paper and by the time I was at college (16-18) I was convinced of my own brilliance.

At the end of college before going to university I worked briefly in the game world, helping do ports of the Scott Adams games to UK machines and bits of some other games, then my own game. That taught me a certain amount about the computing and real world. The computer game business at the time was run by the people who failed to get into the music industry because they'd have to think a moment before selling their grandmother. It was also full of people who were all as good at computing and many of them rather better than I was. Worse yet, every one of them was either as convinced of their own brilliance as me, mentally unstable, or both.

Like the music industry nobody in the computer game industry made any money but mysteriously all the game company owners drove expensive cars and lived in huge houses.

University was a slightly checkered career, not on the whole due to taking other people's computers apart but because of the rather odd rules at Aberystwyth. I learned a lot there (more from my own experiments and trying to achieve things than from the course), but because of the other courses you had to pass (Physics in my case) ended up changing university to one that didn't require I could do physics but required I could do computer science.

Looking back on university I'm very glad I did it. At the time I thought management skills, software engineering, databases and even bits of maths like proof by induction were completely irrelevant. I've used all of them in my Linux work.

The whole Linux thing was really an accident - my interest was text based adventure games (the world of Colossal cave etc) and also multi user games based on that style (Essex MUD1 and so on). I got into Linux looking for a better platform to developer AberMUD on.

I ended up doing time synchronization across ethernet, a large C++ network file/project manager, and then ISDN code for Sonix and later 3COM. I then escaped to be a sysadmin at NTL, left to work at a small saner ISP (Cymru.Net) which NTL bought. At that point I escaped to Red Hat and Linux became a job.

That wasn't actually an easy decision. It probably has many people thinking "So why didn't he go to Red Hat earlier, surely they would have taken him on". I probably should have, but to turn a hobby into work always risks losing the fun factor. It was actually something I had to give a lot of thought. When it came down to working on Linux or working for a telco again however that made the decision easy. 

Initially Alan Cox used to work on the networking and SMP aspects of Linux kernel as well as taking a major role in the "making things happen to occur" by maintaining a stable version of Linux kernel, the job for which Linus Torvalds proved to be not well suited. It was work on networking stack that launched Alan Cox in the prominent position in Linux community.

Initially Linux did not have TCP/IP stack build-in and this situation lasted until probably 1993. Before that it was a separate package created and maintained by multiple developers. Actually TCP/IP stack was the first major subsystem that was developed almost completely without Linus participation (Linus never was strong in networking). It also nicely illustrated the power and role of Usenet community in Linux success.  Essentially the facts are that as for IP-stack Linux was somewhat late to the Internet, but managed to catch up just in time when WEB became widely available (1994).  Here how the history is described in Linux Networking-HOWTO (Previously the Net-3 Howto) General Information about Linux Networking.

Developing a brand new kernel implementation of the tcp/ip protocol stack that would perform as well as existing implementations was not an easy task. The decision not to port one of the existing implementations was made at a time when there was some uncertainty as to whether the existing implementations may become encumbered by restrictive copyrights because of the court case put by U.S.L. and when there was a lot of fresh enthusiasm for doing it differently and perhaps even better than had already been done.

The original volunteer to lead development of the kernel network code was Ross Biro <[email protected]>. Ross produced a simple and incomplete but mostly usable implementation set of routines that were complemented by an ethernet driver for the WD-8003 network interface card. This was enough to get many people testing and experimenting with the software and some people even managed to connect machines in this configuration to live internet connections. The pressure within the Linux community driving development for networking support was building and eventually the cost of a combination of some unfair pressure applied to Ross and his own personal commitments outweighed the benefit he was deriving and he stepped down as lead developer. Ross's efforts in getting the project started and accepting the responsibility for actually producing something useful in such controversial circumstances were what catalyzed all future work and were therefore an essential component of the success of the current product.  

Orest Zborowski <[email protected]> produced the original BSD socket programming interface for the Linux kernel. This was a big step forward as it allowed many of the existing network applications to be ported to linux without serious modification.  

Somewhere about this time Laurence Culhane <[email protected]> developed the first drivers for Linux to support the SLIP protocol. These enabled many people who did not have access to Ethernet networking to experiment with the new networking software. Again, some people took this driver and pressed it into service to connect them to the Internet. This gave many more people a taste of the possibilities that could be realized if Linux had full networking support and grew the number of users actively using and experimenting with the networking software that existed.  

One of the people that had also been actively working on the task of building networking support was Fred van Kempen <[email protected]>. After a period of some uncertainty following Ross's resignation from the lead developer position Fred offered his time and effort and accepted the role essentially unopposed. Fred had some ambitious plans for the direction that he wanted to take the Linux networking software and he set about progressing in those directions. Fred produced a series of networking code called the `NET-2' kernel code (the `NET' code being Ross's) which many people were able to use pretty much usefully. Fred formally put a number of innovations on the development agenda, such as the dynamic device interface, Amateur Radio AX.25 protocol support and a more modularly designed networking implementation. Fred's NET-2 code was used by a fairly large number of enthusiasts, the number increasing all the time as word spread that the software was working. The networking software at this time was still a large number of patches to the standard release of kernel code and was not included in the normal release. The NET-FAQ and subsequent NET-2-HOWTO's described the then fairly complex procedure to get it all working. Fred's focus was on developing innovations to the standard network implementations and this was taking time. The community of users was growing impatient for something that worked reliably and satisfied the 80% of users and, as with Ross, the pressure on Fred as lead developer rose.  

Alan Cox <[email protected]> proposed a solution to the problem designed to resolve the situation. He proposed that he would take Fred's NET-2 code and debug it, making it reliable and stable so that it would satisfy the impatient user base while relieving that pressure from Fred allowing him to continue his work. Alan set about doing this, with some good success and his first version of Linux networking code was called `Net-2D(ebugged)'. The code worked reliably in many typical configurations and the user base was happy. Alan clearly had ideas and skills of his own to contribute to the project and many discussions relating to the direction the NET-2 code was heading ensued. There developed two distinct schools within the Linux networking community, one that had the philosophy of `make it work first, then make it better' and the other of `make it better first'. Linus ultimately arbitrated and offered his support to Alan's development efforts and included Alan's code in the standard kernel source distribution. This placed Fred in a difficult position. Any continued development would lack the large user base actively using and testing the code and this would mean progress would be slow and difficult. Fred continued to work for a short time and eventually stood down and Alan came to be the new leader of the Linux networking kernel development effort.  

Donald Becker <[email protected]> soon revealed his talents in the low level aspects of networking and produced a huge range of ethernet drivers, nearly all of those included in the current kernels were developed by Donald. There have been other people that have made significant contributions, but Donald's work is prolific and so warrants special mention.  

Alan continued refining the NET-2-Debugged code for some time while working on progressing some of the matters that remained unaddressed on the `TODO' list. By the time the Linux 1.3.* kernel source had grown its teeth the kernel networking code had migrated to the NET-3 release on which current versions are based. Alan worked on many different aspects of the networking code and with the assistance of a range of other talented people from the Linux networking community grew the code in all sorts of directions. Alan produced dynamic network devices and the first standard AX.25 and IPX implementations. Alan has continued tinkering with the code, slowly restructuring and enhancing it to the state it is in today.

PPP support was added by Michael Callahan <[email protected]> and Al Longyear <[email protected]> this too was critical to increasing the number of people actively using linux for networking.  

Jonathon Naylor <[email protected]> has contributed by significantly enhancing Alan's AX.25 code, adding NetRom and Rose protocol support. The AX.25/NetRom/Rose support itself is quite significant, because no other operating system can boast standard native support for these protocols beside Linux.  

There have of course been hundreds of other people who have made significant contribution to the development of the Linux networking software. Some of these you will encounter later in the technology specific sections, other people have contributed modules, drivers, bug-fixes, suggestions, test reports and moral support. In all cases each can claim to have played a part and offered what they could. The Linux kernel networking code is an excellent example of the results that can be obtained from the Linux style of anarchic development, if it hasn't yet surprised you, it is bound to soon enough, the development hasn't stopped.

Since 2000 he was employed by Red Hat as a consultant and his work helped Red Hat to remain on the top of "Linux distribution wave" for many years. It is interesting to note that at for several years (I think somewhere between 1998-2002 the administrative utilities group icon in Red Hat was a miniature profile of Alan's head ??? more correct dates needed). Before joining Red Hat Alan was the technical director of Communed (may be he still is). Other his previous jobs include Cable Online and the 3Com Corporation.

He maintained an production kernel for versions 2.2.x, version that proved to be very stable and that essentially launched Linux into corporate environment, and then his own versions of the 2.4 kernel ( "ac" branch). This branch was the most stable version of Linux kernel available.

Here is an interesting observation from LWN.net weekly edition about the fact that distributors generally ignored Linus version of the tree and used Alan Cox version:

Where does kernel development stand? The current kernel development situation is, perhaps, unprecedented in Linux's history. It's interesting to look at what's going on:

• There are currently two "stable" 2.4 kernel trees, which differ significantly. The two competing virtual memory implementations are the biggest difference, of course, but there are others as well. The "-ac" series contains a number of changes which have not, yet, made it into the Linus kernel. Merging changes has been made more difficult by the degree of divergence between the kernels, meaning that stuff is moving into the Linus tree at a slower pace.

  There is also an increasing level of grumbling from various kernel developers, who are finding themselves having to support two different stable trees. There is a fair amount of work (example) going into that support.
   

• There has been no development kernel since last January. Given that the kernel was (kind of) in a feature freeze for some time before the 2.4.0 release, it has been over a year since there has been a real target for new kernel developments. It's no wonder that development-like things are finding their way into stable kernel releases.

Some of the troubles, certainly, could be addressed by opening up the 2.5 series. With a real (single) development kernel to hack on, people would be less inclined to try to get bleeding-edge stuff into a 2.4 kernel.

But that still leaves the question of what will happen with the 2.4 kernel. Linus generally leaves the stable series behind when he starts a new development kernel; in the recent past, the responsibility for the stable kernel has then passed on to Alan Cox. But Alan is maintaining a different, 2.4-based tree, and intends to continue doing so. He states that it will take "another 5 or 6 releases" to get the new VM truly stable, and is thus unlikely to adopt it into his kernel for some time.

Interestingly, though, most distributors base their kernels off the "ac" tree, not the mainline Linus kernel. Conceivably, once Linus moves on to 2.5, his 2.4 series could begin to look like a dead end. That may look like an unlikely outcome, but, unless somebody backs down on the VM issue, a unified 2.4 is looking unlikely in the near future.

During this period he was as powerful (or even more powerful) figure in Linux world as Linus Torvalds. He role as an owner of production Linux kernel proved to be extremely beneficial to the whole Linux community as he managed to compensate for obvious Linus personality problem:  "Linus is a good developer, but is a terrible engineer," said Cox in one of his interviews  "I'm sure he would agree with that."  And it was Alan who converted half-baked "production" kernels into more workable state by working often day and nights. His productivity was amazing: it was a man who was worth a dozen of developers.

As Alan mentioned in one of his interviews, he and Linus Torvalds have different approaches to fixing a problem. Torvalds tries to keep the kernel code that is easy to maintain and in case of problems prefer to re-write the component to a better design. This is often disruptive for production version of the kernel while Alan Cox was able to implement alternative (and often more difficult solution) of  insuring kernel stability by doing fixes to the existing code. Deciding what bugs to fix in the Linux kernel is not always easy, as fixing one bug often impacts other applications. Cox used the strategy when he used to give the top priority to bugs that are reported soon after the release candidate is made available. 

Still destile working on a stable version of the kernel, his position was rather unstable with Linus controlling the development kernel which at some point became a production kernel. Alan did not have much say in determining what technical decisions were make as for the future development of the kernel. Linus ruled as a dictator and it is pretty difficult to work with a dictator, even a benevolent one. Here is how he answered the question about his relations with Linus in his January 2002 interview to Jeremy Andrews (Kerneltrap):

JA: Do you consider Linus a friend?

Alan Cox: Business associate perhaps. We are very different people. Linus is terribly reserved, quiet and neat. I'm none of those and don't intend to be. Live fast, die old, and make very sure everyone knows you were there.

He managed to continue maintaining "production tree" until late 2002.  At some point he stepped down

JA: Many were surprised (and disappointed) when you announced that you were not interested in maintaining the 2.4 kernel tree. What caused you to make this decision?

Alan Cox: A variety of things were involved in that decision. In part I want to work on other projects and ideas. I've already been using some of the time freed up to rewrite the aacraid driver and to clean up some of the very old and grungy SCSI drivers instead. It's also good that a system doesn't settle down with a sort of elite who created it and that new ideas and younger people are always stepping into the project. I want to be sure that when I'm an old fart there are plenty of people in the community with both the knowledge and the standing to call me an idiot when I say something stupid, rather than treat my words as gospel.

Some of the attitudes people had after the decision were annoying. The vision most people have of Brazil is bizarre. Its not the third world that people seem to think. Yes it has its problems, but it is one of the ten largest economies in the world, and overall it has lower crime rates than the UK or USA. Its a source of huge amounts of innovation and many great projects - including things like Window Maker, and apt for RPM. 

... ... ...

JA: Marcelo Tosatti is now maintaining the 2.4 tree. You even suggested him yourself. Why did you recommend him, above others? How do you feel he's doing so far?

Alan Cox: I sort of shadowed Marcelo the first release without telling him. His 2.4.17 looked a lot like my collection. The differences were minor and quite reasonable. I'm extremely happy with the way Marcelo is turning out kernels and also dealing with people. He got a lot of people trying to push him around at the start, and a deluge of journalists but has survived very well.

JA: The "stable" 2.4 series has had a bumpy ride, most noticeably with a complete change in the VM. How stable do you feel the current 2.4.17 release is, in comparison with the 2.2 series? Are there reasons why people may still not want to upgrade business critical servers?

Alan Cox: A prior major release is always going to be much much more stable. Many people run the 2.2 tree on critical systems because it does what they need and it has stayed up for years. There is no deliberate vendor enforced upgrade system in the free software world so people can choose older code. It's a good idea for many projects.

2.4.9-ac and 2.4.9-RH (the Red Hat errata kernel) I was pretty happy with. The 2.4.17 tree is getting there, with Ben's recent fixups and a bit more tuning I think it will turn out nicely. I'm never truly happy until the box stays up for so long that I only reboot to do a major upgrade.

JA: Where do you think this tuning most needs to occur?

Alan Cox: That's always the problem. When you know what needs tuning the job is almost done. The lower disk throughput seems to be caused by the VM layer but at the moment I don't know for sure it isn't some of the disk scheduling  changes.

JA: Linus agreed that the major changes he made to the VM in a "stable" kernel tree were ill-timed, however claiming, "I think that Alan will see the light eventually." Are you happy with the new VM?

Alan Cox: Not really. I'm seeing 20% slower performance on a lot of real world workloads and while that is likely to be a bit of tuning it should have happened in 2.5. I don't think the Andrea VM is technically superior and that the scale of change was right. Once Linus had done it however there was no point going backward. By 2.4.15/6 various bits from Rik and Marcelo and others had the tree in a state where everyone agreed that it was better to start future VM work from that point. Rik is doing a revere map based VM now which is interesting and Andrea is tuning the VM stuff he did for 2.4. 

JA: You still maintain the stable 2.2 kernel, the most recent release in that series being 2.2.20. In the changelog building up to this release was a controversial tag, "Security fixes. Details censored in accordance with the US DMCA". What prompted you to censor these fixes? Was it intended as a political statement, or done out of fear of possible prosecution?

Alan Cox: It was simply a matter of following the law and avoiding liability. The fact that American citizens are forbidden by their own government from hearing, or speaking the truth turns itself into a political statement.

It's an unfortunate situation when the major Linux conference pretty much has to be in Canada because the US will not let some of the attendees even pass through their airspace, and many of the others fear to visit. I just hope that over time things will improve.

At the moment the US, UK and much of the EEC slide slowly toward a police state. Innovation is hard, and innovators are generally buried in courts by established interests. I don't want to become a citizen of the new soviet union, forbidden from watching DVD's from the outside world, from burning flags in protest, and risking jail for offending a large company. People have to get involved in fighting such things. If they do not fight, they may well be swimming to Cuba, or serving in restaurants in Mexico City while trying to
avoid deportation within thirty years.

I'm working with FIPR (the foundation for information policy research) to do my bit. It's up to everyone else to do their bits too. 

... ... ...

JA: Back to Linux, at what point, if any, will you stop maintaining the 2.2 kernel?

Alan Cox: I guess when nobody is using it. It takes a lot less effort to just keep a very stable tree ticking along. There are still people intentionally shipping 2.0 based products even today.

JA: Do you foresee maintaining a stable 2.6-ac branch, when the 2.6 stable tree is started?

Alan Cox: I haven't thought that far ahead.

JA: Does 2.5 development get much of your focus?

Alan Cox: Right now basically none. I was pondering collecting together driver and other stuff to feed on to Linus as he worked on the bio but Dave Jones has already started doing a good job on that.

JA: A lot of kernel hackers greatly admire you and your Linux efforts. You certainly have an amazing ability to organize and create stable kernels. For example, during the unstable period of 2.4, your -ac series proved to be quite solid on all my servers, as reported by many. In regards to your own accomplishments, what do you most take pride in?

Alan Cox: The 2.4-ac tree turned out very well. It was never something I set out to make a big thing but it ended up being used as the base for most 2.4 vendor released kernels. That was a big thing, not just for the code quality, but also because it showed everyone is still working together. 2.4-ac was built out of patches from many places, and I think almost every vendor, put together by someone at Red Hat and in various variant forms shipped by many other companies.

Probably the greatest thing has been seeing all that Linux has made possible around the world, many of which with proprietary licenses charged in US currency simply could not have happened. Being able to say "have a copy, have as many copies as you want, make changes, localize it, build an entire local computing industry" to anyone in the developing world is something very special. Even in the developed world its created so many great things, like the LTSP (Linux Terminal Server Project) putting Linux in schools that simply could not have afforded to do it any other way.

I always like to say "_Em_powered by Linux". 

JA: You released 2.4.18pre3-ac1 last Sunday (1/13), the first since 2.4.13-ac8 in early November. What prompted this release? Do you intend to actively release the -ac kernel patches again?

Alan Cox: People kept bugging me. It's a mix of the stuff I actually run here and a trawl of the stuff that I had piled up during the change over - I found a lot more than I expected that was in my pile that was before Marcelo took over and escaped merging. Most of it is stuff I need to send on - so its not like the huge -ac patches of old, just some handy bits.

I'll probably stick out an ac2 soon as well.  

JA: The 2.2 tree is quite solid, and hence few changes are made. Your -ac series is no longer the huge patch "of old". What do you do with all this reclaimed time?

Alan Cox: Sleep.

Some of it is being spent doing drivers, other bits working on new things and some is beginning to get spent on projects big Red Hat customers need and which will benefit Linux as a whole. 

JA: Do you use Linux exclusively, or do you use other operating systems as well?

Alan Cox: I run Linux on pretty much everything except the microwave and washing machine. Those are tempting targets but would probably make Telsa extremely cross. 
 

He also acted as a CERT vendor contact point for Linux security issues and in this role he used to complain about Linus fixing security bugs behind everybody's back; essentially trying to hide them form anybody but malicious hackers (who of course will compare each and every version of the kernel for such fixes ;-)  out of pure vanity. For his current view about computer security see a very interesting interview that he gave in September 2005 to O'Reilly (see O'Reilly Network The Next 50 Years of Computer Security An Interview with Alan Cox).  

Here is one of his recommendation for those people who try to start working with Linux kernel:

JA: Do you have any advice to offer people just getting started with kernel hacking?

Alan Cox: Ignore everyone who tells you kernel hacking is hard, special or different. It's a large program, and bug fixing or driver tweaking can be a best starting point. It is however not magic, nor written in a secret language that only deep initiates with beards can read.

Play with it, try things, break it horribly and enjoy yourself. I started on the networking code because it didn't work very well. Everything I knew about TCP/IP I had downloaded the same day I started hacking the net code. My first attempts were not pretty but it was *fun*.  

As a final part of this small biographical sketch you might find interesting checking his predictions made in his January 2002 interview to Jeremy Andrews (Kerneltrap):

JA: Do you have any predictions as to the future of Linux?

Alan Cox: For the next five years I guess (and its definitely a guess)

• Linux in TV sets/set top boxes becoming much more common
• More consolidation
• A lot of work on clustering and fault tolerant Linux
• Limited desktop penetration, at least until some lawmaker or civil litigants have the guts to get a just settlement out of Microsoft.
• People figuring out which software models work best and where
• Vastly more software development moving from the EU and USA to Eastern Europe, Brazil and the like, both in Linux companies and outside.
• Just possibly IBM becoming a Linux vendor proper perhaps by buying out the rest of SuSE.
• Possibly Linus becoming directly paid to work on Linux, perhaps via OSDL or a standards group so he isn't "owned" by a vendor - should transmeta die.

(I figure lots of predictions is best. People will forget the ones I get wrong and marvel over the rest)

BTW, he made a right call with prediction the Linus moving to OSDL, which really happened in June, 2003. See Slashdot/Linus Moves To OSDL, Will Work On Kernel Full-Time.

Awards

In 2005 Alan Cox, was awarded a lifetime achievement award at the  Linuxworld in London. In 2003 he was awarded the Free Software Foundation's 2003 Award for the Advancement of Free Software at the FOSDEM conference in Brussels.

Webliography

• Alan Cox - Wikipedia, the free encyclopedia
   

•  Linux pioneer wins lifetime achievement award - ZDNet UK News

  Alan Cox, sometime maintainer of the Linux Kernel and well-known open source advocate, picked up a lifetime achievement award at the LinuxWorld awards in London on Wednesday night.

  Picking up the award in front of a rapturous crowd, Cox stressed the strength of open source development. "Open source works because we all walk the path together," Cox said. "Whether the path is hard or easy, if you have OK people at your back anybody can walk any path."

  Cox, who lives in Wales, has been involved with the Linux kernel since 1991, and was often considered number two in the Linux movement behind Linus Torvalds.

• Alan Cox
   

• Alan Cox's shadow.cabi.net
   

• Linux UK
   

• Building Number Three

• Alan's Diary - (http://www.linux.org.uk/diary/)
   
• Telsa's Diary - (http://www.linux.org.uk/~telsa/Diary/diary.html)

Etc

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

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

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.

Last modified: March 12, 2019