So you've just installed GNU/Linux and it turns out things are running smooth, but the battery doesn't seem to last as long, no one told you about this! You expected better performance, not worse! Well, fear not, it's not a problem with GNU/Linux, it's just a problem with a very specific driver. This problem only appears to be effecting intel-based machines, which is odd as intel typically has phenomenal support with GNU/Linux, and honestly, it probably only really stands out to people using thin, portable laptops without a heavy focus on gaming.
So what's to blame? intel_pstate, that's what. This driver is in charge of determining which speeds your CPU can run at, as well as when to pick up the pace and when to slow down. The problem with intel_pstate is that for the past seven months or more at the time of writing this article (2015.07.23), almost all intel CPUs run hot and are being redlined by the frequency scaling driver. Initially I was informed that intel cpus are intended to idle at high frequencies to allow power quickly when needed. This may be true in Windows and OS X, but it's not working as intended in GNU/Linux. Following is how we go about fixing it.
First, we need to disable the intel_pstate driver at boot. The best method to accomplish this is by adding
to your kernel arguments. The exact location to add this varies by bootloader.
EDITOR=vim sudo -e /boot/loader/entries/$ENTRY.conf
optionsroot=/dev/sdxy rw quiet intel_pstate=disable
EDITOR=vim sudo -e /etc/default/grub
EDITOR=vim sudo -e /boot/syslinux/syslinux.cfg
Now that intel_pstate's been disabled, the system should fall back to acpi-cpufreq as the frequency scaling driver, usually with the "ondemand" or "userspace" frequency governors which tends to run the CPU at about 50% of the max speed, so you should see a fair jump in battery life just from that step, though you can take it a bit further with other utilities, like laptop-mode-tools (or tlp, but you can't run both), cpupower, and acpid.
This daemon basically allows for management of your system through specific acpi events, like closing the laptop lid, hitting the power button, or reaching a specific battery percentage, which can be useful for a variety of reasons, but the main use I had for it was setting up suspend when I close my laptop, fortunately that works out of the box. It also has the acpi command which gives you battery estimations in the command line.
This allows for unified configuration files to manage your system and try to get the battery life you deserve. It does have a configuration file for intel_pstate which may help mitigate the problem with only this tool, but I've found that the acpi-cpufreq driver allows for more control over CPU performance. Once installed, setting the following variables will set your CPU frequencies.
EDITOR=vim sudo -e /etc/laptop-mode/conf.d/intel_pstate.conf
EDITOR=vim sudo -e /etc/laptop-mode/conf.d/cpufreq.conf
This tool allows you to see your cpu frequency, frequency scaling driver, frequency governor, and even set those parameters manually.
cpupower frequency-info # shows current CPU info
sudo cpupower frequency-set -g powersave # sets the frequency governor to powersave
Those are really the only steps I've been able to take to get my battery life back under control on my MacBook Air, prior to this driver, or at least driver update, I could get 12+ hours of battery life without issue, and my MacBook was almost always cold to the touch, after the update, I was lucky to get 2 hours and it was always hot, with this workaround it gets around 6 hours of battery life. Hope it helps anyone in a similar situation.
Edit on 2016.01.03: modifying the commands to a safer method of editing system configuration files, assuming the user is currently using BASH as their shell. If you happen to prefer something like tcsh, like myself, you'll need to run the following command to specify your preferred editor, I happen to like vim. Thank you to /u/moonarch and /u/Trout_Tickler for bringing this to my attention.
setenv EDITOR vim
This issue with the intel_pstate cpu frequency scaling driver seems to be resolved as of kernel version 4.5. I only have access to Haswell based computers, but I've heard that Broadwell is experiencing similar issues with the driver, without access to a Broadwell machine, I won't be able to provide any accurate information regarding battery life and efficiency, but the steps involving cpupower, acpid, and laptop-mode-tools should help extend battery life if you run into this issue on any platform later than Haswell.