Re:Drgn: How the Linux kernel team at Facebook debugs the ke...
by onion2k on Tuesday December 14, 2021 @02:52AM
(#29549309)
That's a problem where you had no real choice to do anything else by the sounds of it though. You couldn't just "turn it off and on again" to fix it. In the case of a server where you can just have health check that reboots the server if memory gets a bit too low, it's far simpler just to automate a power cycle. It's not laziness or incompetence; it's understanding where to spend your effort best.
[ Parent
| on HN ]
Re:Drgn: How the Linux kernel team at Facebook debugs the ke...
by xorcist on Tuesday December 14, 2021 @03:51AM
(#29549621)
It's not that simple. Intermittently rebooting touchscreens make for a bad user experience.
User experience is one of those things that doesn't matter until it suddently does, often when a competitor sells a product that doesn't reboot in the middle of a user operation.
Re:Drgn: How the Linux kernel team at Facebook debugs the ke...
by ajuc on Tuesday December 14, 2021 @03:02AM
(#29549365)
If we had memory leaks caused by drivers we would have to debug them all the way as well, restarting the device every few hours wasn't an option.
Re:Drgn: How the Linux kernel team at Facebook debugs the ke...
by onion2k on Tuesday December 14, 2021 @03:43AM
(#29549580)
Exactly. We all choose the most cost effective solution - it's a balance between engineering effort and how effective the fix is. In the case of a touch screen, rebootingit every few hours isn't as effective as debugging the underlying cause. In the case of a web server having a memory leak, killing a pod and bringing up a new one automatically when it gets unhealthy definitely is. It's not surprising that each dev team settles on different solutions to each problem.