Exactly, the sweet spot (for natural gas) is about 40F to 45F Outside, as natural gas (here) is generally about 1/3 the cost/btu as electricity (and sales tax is not charged on heating fuels in the winter - but you can only have one fuel designated as a heating fuel). I would think someone who has to use propane or oil (or even wood) would have a sweet spot at a much lower temperature; as, those fuels are much more expensive. You always need a backup to the heat pump. Resistive heat is a good choice if you don't think you will ever need it.

FVWM2 already does a simple mosaic layout (if the window's default size does not fit in the open space, it asks the user to place it). Also - fvwm2 uses less system resources (lower overhead - and thus less energy - and very little space for settings). It also makes it extremely easy to switch virtual desktops (Ctrl+arrow) each desktop can be considered a workspace. The hard part is deciding your virtual desktop layout (I like vertical - with the pager on the right, so I use 16 vertically stacked desktops - ctrl+up-arrow/down-arrow - vertically stacked makes the pager just a skinny strip on the right of the screen).

Or FreeBSD - which is a bit more lax on security (but still is considered better than even Linux - when run correctly). I think things are missing (like filesystems,and VM support) both for security and for hardware compatibility reasons. openBSD is also know to run on more hardware than most other OSes (which makes it useful for some specialized tasks - and makes it a good utility OS). And it can be installed with a very small footprint. It would be nice if they added ZFS to the supported filesystems (even better if they could boot from ZFS like FreeBSD does). The security of OpenBSD is more than just disabled services, it also includes the lack of "security features" which reduces complexity (thus making it easier to make secure). Simplicity is the bedrock of good security. There are also many things about the kernel itself that improve security.

Simply disabling services by default, would make Linux and Windows much more secure out of the box.

The article suggest that OS setting of the BIOS is rare. It is actually common (even before UEFI). Most people run firmware updates from the OS. Dell has for many years supplied a program that you can use to set all the BIOS settings on your Dell machine (they even have one that runs under Linux - the good thing is you have to have the BIOS password to use it or update the bios firmware). Unfortunately, UEFI allows the OS to set the boot order even if the BIOS password is set. So - yes (instead of a switch) - I think that any update to the bios or BIOS settings through the OS interface should cause a BIOS pop-up on the monitor (that can't be captured with VNC, etc) that must be answered with a keyboard response (like Y). This of course should be a security setting in the bios (but ONLY settable via the keyboard).

And the minute administrators figure out how to turn autorun off, Microsoft changes the mechanism to bypass those settings. Watch them change the policy key you have to use (NOTE - you can use the policy registry tree, most even work on Windows Home).

Autorun isn't that smart.

I am sure the USB drive is also set to use autorun to run the link. Using USB devices is a security problem anyway. It is more complicated, but use a usb CD/DVD drive to boot rescue utiliies and install an OS (as you can guarantee it is read only). The read-only switch on a usb stick is just a suggestion (like it is on floppy drives). Although a USB drive could be built that enforces the read-only switch (even if the computer wants to ignore it) - personally, this should be the standard.

Use full user/admin separation (a seperate admin account, that you never use for user stuff). This is the mode you should use on ANY os (Linux, MacOS, etc) even though they all seem to push you to the one account mode (very bad security). I have been doing this since Windows NT. It solved all the annoying issues of Windows Vista (which is basically Windows 7 with the UAC set to max protection). It will solve the issues with the UAC in the same way (if you are really anal about not running user programs as Admin, you can even safely turn the UAC off). You will completely eliminate the UAC prompts for regular users, if you set it to silently deny elevation requests from non-admin users. The UAC does not protect against network attacks from machines that are not running the UAC (by admin users), nor even network attacks from an elevated process from another computer (running as an elevated admin that has access to the original machine). So you should never depend on it, and always assume it allow anything. If you are developing software - put the UAC on max security.