A problematic bug in simple-init can be resolved by eliminating one variable. Specifically, change:-
$wait=60*60*24;
while($active&& $running) {
(undef,$wait)=select(undef,undef,undef,$wait);
}
to:-
while($active&& $running) {
select(undef,undef,undef,60*60*24);
}
or suchlike. This change eliminates the case where the variable is zero and a busy wait on select() ensues.
Minor bugs remain. Regardless, simple-init is now suitable for deployment on systems which do not require suspend.
(Score: 2) by cafebabe on Friday August 19 2016, @12:15AM
For downward compatibility, the code was intended to run on Perl4. For really obscure reasons, I hoped that any surplus energy consumption on a dormant system would occur at the same time every day (or drift so slowly that observed output was functionally similar). Unfortunately, this led to a lapse where I didn't consider the granularity of select() or the case where the input was zero. This case most typically occurs when a system is under load. Even then, it typically consumes 1/n of the processing power (or one core of processing power when there is no load). This is annoying inefficient and now resolved.
It is preferable to keep dependencies down - especially in an init system. As a further example of keeping dependencies down, the LAMP application being developed in my venture has a 2KB shim of Perl4 which locates a Perl4 library loader. This works even if the application is invoked via multiple nested symbolic links. This may seem like a major overkill but it ensures that the application works consistently on crufty systems and also where there is no root access on a system. This reduces the bloat and technical debt where it is now typical to use a container. Although container creation is fast and covers many cases, the downside is that each container is subsequently dependent on security fixes.