To reproduce the issue:
	$ slstatus -s | tee

then it would print only when the stdout buffer is full, by block
of multiple lines.

fflush() makes sure the line is printed at every loop iteration

sys/sensors.h has two structs struct timeval: sensor and ksensor:

	struct sensor {
		...
		struct timeval tv;		/* sensor value last change time */
		...
	};

- Sort Alphabetically
- Same indentation for preprocessor clauses

OpenBSD's entropy design is superior to Linux.

- Use block for single statement ifs
- Keep lines to reasonable length (current debate as to reasonable)
- When functions return -1 for error test against 0 not -1
- Do not indent cases another level
- Do not test against NULL and 0 explicitly
- Use tabs for indentation, use spaces for alignment

The third value from load_avg (idle) gives us almost the same
information as cpu_iowait. Plus OpenBSD does not offer an iowait value
as Linux and thus the corresponding function would not be portable.

In OpenBSD the CPU usage in percent is now computed using KERN_CPTIME
sysctl.

It does not respect charging thresholds and it is not trivial to
implement the indicator in OpenBSD.

- Battery power cannot be easily gatherable via apm(4)
- IMHO it does not represent essential information

Be consistent with brackets and add a comment for OpenBSD to make it
clearer what the actual intent of the uncommented line is.

In the Makefile, add a dependency of slstatus.o from config.mk.

Granted, this style is definitely not common, but for the short
utility-functions of this program it's just the right choice. This
provides great flexibility, such that in the long run, it will be
possible to also share code between the OS-implementations.

This also keeps the state-keeping at a minimum and makes it clearer
which functions are implemented on which OS without having to jiggle
around with too many files in the process.

this reverts the commits from 92ab9ef52e up to
d42870d6ca.

After heavy consideration, the component split has more disadvantages
than advantages, especially given there will be utility-functions
sharing quite a lot of code that would then need to be duplicated, as it
does not fit into the util.c due to its speciality.

One big advantage of the component-wise build is readability, and
without doubt, this was achieved here. This point will be addressed
with a different approach that will be visible in the upcoming commits.

One big disadvantage of the component build is the fact that it
introduces state to the build process which is not necessary. Before its
introduction, the only influencing factors where the system-defines
__linux__ and __OpenBSD__. With the components, we are also relying on
the output of uname(1).
Additionally, if the os.mk is not present, make gives the output

     $ make
     Makefile:5: os.mk: No such file or directory
     make: *** No rule to make target 'os.mk'.  Stop.

This could easily be fixed by providing some sort of meta-rule for this
file, however, it indicates the problem we have here, and this entire
statefulness will heavily complicate packaging of this tool and makes
the build process much more complex than it actually has to be.