Long uptimes.

Levi Pearson levipearson at gmail.com
Wed Nov 18 10:02:14 MST 2009


Michael Torrie <torriem at gmail.com> writes:

*snip*

> But even on linux, a kernel update requires a reboot.  Often the kernel
> update is critical because of a local exploit that it fixes.  Why do we
> have to reboot just to patch a kernel?  Sure it sounds complicated to
> patch a running kernel, but if I recall there were systems in the 70s
> that could do this.  There must be mechanisms that could be used to
> facilitate this in modern Linux kernels.  But like the Microsoft
> programmers, Linux programmers (aren't we all) are inherently lazy and
> shift the costs in a similar way.

I'm pretty sure people have made experimental implementations of Linux
kernel swapping without rebooting.  But, like everyone else, the Linux
maintainers did some sort of cost/benefit analysis and decided it wasn't
worth the development time to integrate it into the system.

So, bascially what you're saying is that anyone who chooses to implement
a different set of features than you'd like is inherently lazy?  I'm
sorry the world hasn't arranged itself to suit your needs. :)

> Seems to me if we focused on software maintenance (which really means
> more than bug-fixing; think evolution), not only would uptimes be
> ridiculously long, but software in general would be more reliable.  But
> that'd go against human nature.

OK, considering we're all pretty much running some form of a unix or
windows system, none of which have a kernel architecture newer than
sometime in the 90s, and some of which go back to the 70s... wouldn't
you say that their development is focused on software maintenance?

Maybe they're just driven by some metric other than ridiculously long
uptimes.  It would make sense, since to do so would be... ridiculous.

                --Levi



More information about the PLUG mailing list