Linux stores time internally, regardless of your hardware clock (a.k.a. RTC). That means your system can show one time when you run date (Linux clock), and a different time when you run hwclock (hardware clock).
Usually, you would want to load the time from the hardware to Linux when the machine boots (with hwclock -hctosys), and when the machine goes down, you want to store your pretty accurate time (you do use ntpd, don't you? ;)) - back to the hardware clock, with hwclock -systohc.
Now, what happens if your system dies, reboots abnormally, etc? The clock doesn't get synchronized to hardware. On next boot, you might have a large clock skew, because the hardware clock is not that accurate... next time you'll say "I need my system to start with ntpdate before ntpd, because otherwise, ntpd might not sync the time at all, because the delta on the current clock and the real time is too big". The problem with that approach is... what happens if you happen to sync to a machine which by itself is not in sync, and then your ntp will never have the right time?
So in order to avoid all that, it's good to keep the right time synchronized to the hardware at all times. What the kernel option you're asking about seems to do, is to note if your time is actually synchronized with NTP (there is a way to know that...) - and if it is - sync that time regularly from Linux time (a.k.a. System Time), to the hardware clock, so it will be very accurate at all times, including sudden system crashes.
This isn't the xrandr-approach the I know works in X, but for console you can try this — you can write to that /sys/class/drm/card0-DP-1/status file as well. I couldn't find proper documentation, but thankfully Linux is open source. Reviewing the source code, it looks like it takes a few values: detect, on, on-digital, and off.
So echo detect > /sys/class/drm/card0-DP-1/status should force a re-check for a monitor. Or echo on-digital > /sys/class/drm/card0-DP-1/status might manage to turn it on, regardless of what the detection thinks.
edit: Under X, I've used this to deal with HDMI that did not detect being plugged it — it'll force-enable the output. But unfortunately video only, HDMI audio won't work (and apparently isn't possible without a kernel patch):
xrandr --newmode "Mode 2" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
xrandr --addmode HDMI-1 "Mode 2"
xrandr --output HDMI-1 --mode "Mode 2" --right-of LVDS-1
All those numbers specify the video timings; normally it's auto-detected, the easiest way to get them is to grab the mode it's using when you've booted with it so it's working (xrandr --verbose will show them).
Best Answer
In a nutshell, namespaces provide a way to build a virtual Linux system inside a larger Linux system. This is different from running a virtual machine that runs as an unprivileged process: the virtual machine appears as a single process in the host, whereas processes running inside a namespace are still running on the host system.
A virtual system running inside a larger system is called a container. The idea of a container is that processes running inside the container believe that they are the only processes in the system. In particular, the root user inside the container does not have root privileges outside the container (note that this is only true in recent enough versions of the kernel).
Namespaces virtualize one feature at a time. Some examples of types of namespaces are:
Since Linux kernel 3.8, unprivileged users can create user namespaces. This allows an ordinary user to make use of features that are reserved to root (such as changing routing tables or setting capabilities).
Namespaces rely on the kernel to provide isolation between namespaces. This is quite complicated to get right, so there may still be security bugs lying around. The risk of security bugs would be the primary reason not to enable the feature. Another reason not to enable it would be when you're making a small kernel for an embedded device. In a general-purpose kernel that you'd install on a typical server or workstation, namespaces should be enabled, like any other mature kernel feature.
There are still few applications that make use of namespaces. Here are a few:
See the LWN article series by Michael Kerrisk for more information.