Ubuntu – How to handle Puppet version differences between linux distributions

Both Puppet and Chef can do what you want just fine. Your best is going to be to start doing what you're trying to do and decide which tool you like the best. I think the big questions you have to have to ask is:

Do you want a DSL? - Chef recipes are written in ruby, puppet has a DSL. Whether a DSL is good or a bad choice is one of the biggest differences between chef and puppet. The link you posted to bitfield consulting's comparison has some good comments about this you should read if you haven't already. I also found this blog post useful, make sure you read the comments too.

Do you know ruby? - If you don't know ruby, getting started with chef can be harder or require a larger investment of time since you need to learn a new language. Puppet has its own language which is easy to get started with. Starting with puppet 2.6, manifests can be written in ruby too.

At the Open Source Bridge in 2009, they had a panel of the authors and representatives of chef, puppet, bcfg2, cfengine, and automateit which you can watch on bliptv which has 1.75 hours of discussion about configuration management utilities.

Opscode/Chef talks about the difference between it and puppet in their FAQ as well.

I think your not knowing the right questions to ask might stem from you not having too much experience working with either of them, once you start using them you'll start seeing the differences between them. I'd suggest coming with some real life problems you will solve with chef or puppet, then start trying to solve them and see what you like/dislike about them. With Opscode/Chef, they offer a hosted solution that you can set up 5 nodes for free to get started.

.bash_profile and .bashrc are specific to bash, whereas .profile is read by many shells in the absence of their own shell-specific config files. (.profile was used by the original Bourne shell.) .bash_profile or .profile is read by login shells, along with .bashrc; subshells read only .bashrc. (Between job control and modern windowing systems, .bashrc by itself doesn't get used much. If you use screen or tmux, screens/windows usually run subshells instead of login shells.)

The idea behind this was that one-time setup was done by .profile (or shell-specific version thereof), and per-shell stuff by .bashrc. For example, you generally only want to load environment variables once per session instead of getting them whacked any time you launch a subshell within a session, whereas you always want your aliases (which aren't propagated automatically like environment variables are).

Other notable shell config files:

/etc/bash_profile (fallback /etc/profile) is read before the user's .profile for system-wide configuration, and likewise /etc/bashrc in subshells (no fallback for this one). Many systems including Ubuntu also use an /etc/profile.d directory containing shell scriptlets, which are . (source)-ed from /etc/profile; the fragments here are per-shell, with *.sh applying to all Bourne/POSIX compatible shells and other extensions applying to that particular shell.