Mach's designers simply assumed that systems would be rebooted often enough

I'm not going to pretend I know what Mach is, but around here, (big company that you're familiar with), rebooting/bouncing the servers is pretty much how issues are dealt with. "Response times outside of SLA: bounced the server." "Database connections timing out: bounced the server." "Users experiencing high load times for pages: restarted JVMs. Then bounced the servers."<p>Root cause seems to be "server up too long."

I wonder if that's been fixed in the OS X/Darwin version of Mach, seems like the only time I ever reboot my MacBook is for system updates.

My favorite Linux bug (since fixed):<p><a href="https://bugzilla.redhat.com/show_bug.cgi?id=97373" rel="nofollow">https://bugzilla.redhat.com/show_bug.cgi?id=97373</a> (System UPTIME reported incorrectly):<p>"Steps to Reproduce: 1. Boot Linux system; 2. Go away for 497 days; 3. check uptime"

Relevant: <a href="http://www.usenix.org/event/osdi04/tech/full_papers/candea/candea.pdf" rel="nofollow">http://www.usenix.org/event/osdi04/tech/full_papers/candea/c...</a><p>Microreboot – A Technique for Cheap Recovery<p>"A significant fraction of software failures in large-scale Internet systems are cured by rebooting, even when the exact failure causes are unknown. However, rebooting can be expensive, causing nontrivial service disruption or downtime even when clusters and failover are employed. In this work we use separation of process recovery from data recovery to enable microrebooting – a fine-grain technique for surgically recovering faulty application components, without disturbing the rest of the application."

"Hello IT, have you tried turning it off and on again?"

There are some great reasons due to memory fragmentation and other issues to reboot your systems every two or three days anyway. Plus, if you pride yourself on having failover, DR systems, etc, rebooting lets you know that your failover systems are working.