Hacker News Reader

Comment by 999900000999 | Hacker News Reader

I strongly suspect it's just easier from a customer support point of view, if you develop an application that causes the camera to overheat and fail.

They really don't want to send you a new camera. The dangerous thing with code controlling hardware directly, is absent safe guards you can easily exceed the mechanical limits of the device.

This is why seriously overclocking a CPU will definitely void the warranty, but at the same time CPUs are often marketed based on how well they handle overclocking.

View on HN

But in this case, the camera processor still retains final control over the commands from the SDK. This isn't a customer firmware, just a networking interface that simulates pushing buttons and changing menus. The firmware has just as much ability to reject damaging commands as it would if the user was physically entering them.

Not many humans can click a button 30 times a minute for 5 hours straight.

This feels like cya, it probably won't break the camera, but just in case it does .

That was my thought, also. You very well might be able to do things with the SDK that no human can do. The Therac-25 disaster comes to mind--a sufficiently skilled operator could inadvertently command it to become a death ray. (The trigger condition was to change it's operating mode while it was still executing the previous mode change command. Your average operator couldn't enter orders fast enough, but the fastest people could. It was supposed to work at high power with a target in the way to convert the electron beam to x-rays, or at low power as a direct electron beam. Confuse it and you got the high power mode with no target in the way and a fried patient.

An external intervalometer can. And in any case, both in both the SDK and the intervalometer case, the camera's OS is free to just stop functioning, to prevent any possible damage to the sensor or shutter mechanism due to overuse.

So if an application on your PC makes it overheat and break the PC is at fault for being defective and you get to RMA it? What about a laptop? And a Camera is different how?

In the end it would be faulty / bad design that makes the Camera fail. And that is absolutely a valid reason the RMA it.

> So if an application on your PC makes it overheat and break the PC is at fault for being defective and you get to RMA it?

Kernel code can absolutely brick your PC due to how much it can do. This could be fixed at a UEFI/microcode level, but not without taking a lot of control away from the OS and the end user.

Reply on news.ycombinator.com