Por extensibilidad. El día de mañana puedes querer actualizar soft porque hay agujeros de seguridad, o por la razón que sea. Hacerlo todo a nivel de kernel puede ser más complicado.
Bueno, pienso que la aplicación de control no tiene porque ser demasiado compleja (en el sentido de fan-in y fan-out).
Sólo tendría que hacer uso de dos o tres subsistemas del kernel, a través de los símbolos que exporten, sin hacer cosas raras... Así que, con un poco de disciplina el engendro podría mantenerse fácilmente: no pasaría de ser un parche poco intrusivo que se podría aplicar con pocos cambios a varias releases sucesivas del kernel.
Y si realmente quieres simplicidad, para qué modificar una Debian. Utiliza como punto de partida una minidistro que quepa sin problemas en 32 MB.
Además, uno de los requerimientos empresariales es tener los productos *ya*. No vale tener un producto muy bueno dentro de xx meses.
Hombre, cuando hay sistemas empotrados de por medio, interesa que el software sea muy bueno más que tenerlo para *ya*. El soft va a ir replicado en un montón de unidades, así que lo que te ahorras acortando el ciclo de desarrollo, pruebas y tal del mismo es ridículo con lo que puedes ahorrar montando menos memoria en, digamos, el millón (u dos :-)) de routers que salen de tus cadenas de montaje cada año.
La diferencia de precio entre un soft de segunda y otro optimizado te lo ahorras una vez, el sobrecoste de un hardware "más grande" de lo necesario lo pagas cada vez que construyes un router.
[ Padre ]
|
