Standard Linux

Linux has a record of squeezing a lot of performance out of little or old hardware. This is done by relying extensively on strategies that will favor interactive over non-interactive events. For instance, writes to disc can be delayed substantially and Linux will buffer data and reorder it, writing it in a continuous manner with respect to the discs location, and out of order from the user's standpoint. These and other strategies are well-suited to improve average performance but can potentially introduce substantial delays to a specific tasks execution. This is to say that peak delays of a second or even more can occur in GNU/Linux without this indicating any faulty behavior. As embedded systems are generally resource constraint systems such optimization strategies are an improvement in most cases, but increasing system complexity and the potential of a networked system reaching very hight loads (just imagine a network on which many other probably faster systems are broadcasting all kinds of important server announcements...) can degrade the system's response to high priority events dramatically. This is to say that an embedded GNU/Linux system better not have any timing constraints at all and should not rely on the system's catching a specific event. If there are no such constraints with respect to timing, then an embedded system running a scaled down standard GNU/Linux will well suit most purposes and operate very efficiently.