> One could easily poke holes in this complaint; the characterization of PAM as "modern" is somewhat amusing; it is 1990s technology. There is an evident case o

> One could easily poke holes in this complaint; the characterization of PAM as "modern" is somewhat amusing; it is 1990s technology. There is an evident case of cognitive dissonance shown in the simultaneous desire for the comfortable "Posix and Unix" world of decades past and the ability to "innovate and do cool things." It is difficult to simultaneously innovate and stand still, but that is what Marc seems to be asking for here. There's a bit of nitpicking in the above. PAM may not be a new technology, but it's not used by every OS. The problem is the implicit assumption by many devs that it is being used. Multiply this by every choice that the Linux kernel and various distros have made differently than other Unix-like OSs and you end up with a ton of open source software that is effectively locked into Linux. In my (limited) open source experience, most devs using Linux do NOT do this on purpose. They just assume that they're writing UNIX software when they are not. They end up using GNUisms, #defines only available in Linux, assume PAM and other things, ad nauseam. When I've pointed such things out, I usually get a bewildered look. Many Linux people think they're using vi when they're using vim. They don't understand that their sed scripts are really gsed and won't work on traditional sed. They don't know their sh scripts are really bash scripts and break on traditional /bin/sh. And C code is a similar story. In most cases these little things do not improve the code; they only introduce incompatibility. So when Espie uses scare quotes on "progress" and "modern" I get his point. When progress and modern mean an equivalent but incompatible system, then they deserve scare quotes.