A Generation Lost in the Bazaar

I'm not I'd like to get on either side of this argument, but I'd like to point out a steady decline in systems and operating systems (both research and teaching) across the academic world. Rob Pike wrote a polemic touching on it, and he wasn't entirely off base.

This isn't to say that they don't exist, but there are a wealth of examples demonstrating the transition of major progress in those fields to companies like Google and Amazon. For anecdotal examples, see GFS, MapReduce, and Dynamo; there are many unpublished/trade-secret examples that will take years to come out.

Additionally, many schools have reduced their requirements for what exposure students should have to systems and OS:

A Harvard CS concentrator, for example, is not required to take either the introductory systems or operating systems classes; he/she may opt to take a high-level mobile programming class instead. Indeed, the operating systems and distributed systems courses are taught every other year, further reducing enrollment. The last time CS 161 (intro OS) was taught, there were only 23 students. 25 in CS 153 (Compilers). This is a stark contrast to the 100-200 students who took other upper-level CS classes (189 in mobile, for example).

While I will not contest the value of the formal CS education, I see some of the 'naive'(for lack of a better term) CS proliferating even there.

No stop it! Don't defend autoconf, it is not worth it and the software does not deserve it. Users of autoconf, that is developers that try to use that POS to build their software definitely experiences its pains.

It is not just that M4 is a horribly ugly, badly, inconsistent language. You also have about a million leaky caches in the build process to deal with. Autoconf rewrites the build scripts in three stages, each which is cached and also keeps an autom4te.cache directory around. So what happens is that you update something in the M4 build script and then have to spend hours hunting down why the change didn't change anything because some stupid autoconf cache wasn't flushed.

What autoconf has done is to separate free software developers into two categories. Those who can hack the source (the .c and .h files) and those who understand the "autoconf magic." It should be telling that people refer to it as "magic" - it's a fing build system, not rocket science.

The only reason this ugly piece of software has lived on is because people treat it as some kind of magical device and inertia. Configuring and building software is an easy problem. It gets even easier if you finally decide to drop support for 30 year old unices that no one uses. The autoconf team consistently refuses to do that which why the software wont ever become better.

CMake, SCons, Waf and probably half a dozen more tools all do a much better job configuring software than autoconf ever will. People really need to try those alternatives and I'm sure they will realize autoconf needs to die, die, DIE.

You're basically describing the very nature of distributed systems :) We see many more of them nowadays because of the scale of some modern web apps / sites whereas in the 1990s the internet just wasn't that big or that complicated. Whether every app that ends up being that complicated actually needs to be like that is a different question.

It also comes back to "don't reinvent the wheel" and "not invented here syndrome". You _could_ implement many of these things in your homogenous codebase or you could just reuse something that already works. I'm just saying there are serious and good counterarguments to the "large amount of quite homogenous source code written in a single language" approach.

I agree with some of the details (like AMIs, EC2, different types and versions of linux, different package managers in the same system), but I think in general the things you think of as hacks aren't hacks at all and just the signs of progress. Or at least the nature of large, complex modern distributed systems. You basically described the term "agile development" and you're remembering a time many developers would rather forget with rather rose-tinted glasses.

(I don't really know enough about objective-c to comment.)

Not necessarily. Plenty of commercial packages say "made for Redhat X.Y.Z".

The fact that something only runs on iOs means it's a fairly limited piece of software in terms of portability - which is an acceptable tradeoff for many things, but not for others.

I wrote this analogy to explain this situation to my Facebook friends:

Hypothetical cooking analogy for the non-techies: Back in the day, if you wanted to cook up a fancy meal, there was only one butcher in town, and he did things the "right" way. He only used one variety of beef, because it was the "best", and he only sold the "best" cut of that beef. Similarly, there was only one farmer, who only sold the "right" crops, because they had the "right" flavor. When you wanted to cook a fancy meal, you didn't really have any decisions to make, because there was only the "One True Way": one "correct" cut of meat, one "correct" vegetable selection, etc.

Since then, an explosion of variety has occurred. However, perhaps we have swung too far in the other direction. Rather than choosing among the 6 different makers of pasta sauce, you now must choose among 6 varieties of pasta sauce from each of the six makers. This way lies decision fatigue.

However, the community of grocers got together and came up with an ingenious artificial intelligence agent built into a pick-packer system. Now, you don't need to even know a single brand name of pasta sauce. You can simply arrive at the store, tell the system what recipe you are following, tell it that you prefer your tomatoes from Spain, your beef the organic grass-fed variety, and your garlic from the Mediterranean, but you'll take whatever variety of pasta is local and most fresh. The system then assembles your grocery cart automatically for you, and you can choose to remain blissfully ignorant of all of the decision-fatigue inducing choices which occurred under the hood.

However, if you are of the crotchety-old-man sort, and you "Only buy my rib-eyes from Lambert and Sons, because he's the only butcher who does it right", you can of course choose not to use the AI pick-packer, and you can take it upon yourself to select the "best of breed" ingredients for your meal, and pretend that the explosion of variety never happened.

So here's the deal. Poul-Henning Kamp wrote an article lamenting the fact that the explosion of variety happened and that the AI pick-packer was invented, because now everything is a giant mess, and back in his day, there was only one right way to do it, dammit.