Hacker News Reader

Comment by buildbot | Hacker News Reader

Maybe this is cruel, but in some ways I’m surprised modern hardware can be damaged over a modern bus?

I wonder how it damages them.

As I understand it the Kontrol S4 has moving parts (essentially motors) under USB control.

Obviously you could design this sensibly so that no legal inputs result in malfunction let alone damage, but that might cost more, so, do it all in software right? And then you're at the mercy of the software and anything (such as the OS kernel) which that software depends on.

We do teach Computer Science / Software Engineering students not to do this, showing them e.g. the Therac-25 incident as an example of why software control isn't enough - but well, check out how many HN regulars are proud that they either didn't pay any attention in class or never attended and are "self-taught".

SANE (the Free Software document scanner software) has run into cases where it's just cheaper to have code that checks "Is this the end of the bed? If so, turn off the motor" than spend five cents on a limit switch or one cent adding a stop so that the scan head physically can't fall off. Somebody reverse engineering a driver sends "Move scan head" and, to their astonishment, it falls off its rail and their scanner is broken. Oops. Now, who feels comfortable shipping that to users knowing if your finished driver didn't catch every edge case you might destroy their scanner?

Sounds like a nightmare, I guess SANE is an ironic name?

IIUC, that example seems more like an indictment of the scanner manufacturers, not the developers of SANE. SANE includes that code because some manufacturers didn't implement such a simple, obvious, and crucial constraint in the hardware. Unless maybe the poster's point was that the SANE developers shouldn't try to support such fundamentally broken hardware?

I didn't mean to suggest that SANE was a poor project, I guess I just supposed it was sort of gallows humor from developers working on a hard problem.

SANE (Scanner Access Now Easy) is named that way because it does what people on minority platforms assumed TWAIN does on Windows / MacOS.

TWAIN (sometimes said to mean "Toolkit Without An Interesting Name") looks like it's a universal API for scanners, except, the mandatory parts just spin up a graphical user interface and that does all the actual work. There is no actual scanner technology in TWAIN, each scanner comes with its own GUI plus scanner driver bolted into one app.

So in TWAIN there is no API for like "Scan A4 document, 300dpi" only "Make whatever Twain GUI I have appear" and when you buy a scanner it just comes with a CD (I guess these days they tell you to download it probably? I have not set up a new scanner in decades) with the software on it.

But SANE does what people assumed TWAIN did, the GUI application software is neutral, and the code for driving scanners has APIs for scanning documents, because that makes more sense (and also, frankly, "reverse engineering USB code" and "building easy to use GUIs" are not the same skill set). As a bonus it means you can network SANE, just by adding an RPC layer, whereas for TWAIN you'd need like RDP or something. Blergh.

> many HN regulars are proud that they either didn't pay any attention in class or never attended and are "self-taught".

It's because companies want "superstars" (ie: underpaid people with something to prove by spending a whole bunch of unpaid overtime in order to get $50k at the end of 2-3 years when the company is sold)

The truth is in the hardware game, you end up cutting corners in order to deliver something someone will buy because if you're a dollar pricier than the next guy noone will build your plastic AF product.

There are those of us who are "self-taught" who are familiar with Therac-25 and other incidents. Don't think that a college degree somehow magically infuses engineers with ethics and judgement.

That comes from a culture of engineering that focuses on learning and continuous improvement, otherwise we'd just be fixed in time the moment we left school.

I can't speak for other degrees, but mine didn't magically infuse me with ethics. It was the full credited modules solely dedicated to just ethics that aided in that department.

Ethics was an elective module in my CS degree. I took it because it seemed easier than some of the more advanced programming courses. 20 years later, I’m glad for the choice I made as a lazy youth.

In countries like Portugal, where Software Engineering is a professional title, just like in other engineering disciplines, ethics is part of universities being allowed to teach the degree and professionals being allowed to call themselves engineers.

I think an ethics module is pretty rare in CS/engineering degrees.

Can you provide data to back up that assertion? Its definitely a hard requirement for European engineering certification anyway

No hardware vendor would actually design that way. Pretty sure there are some driver ICs for those motors which take care of those spikes. Besides, controlling voltage limits via software is pretty expensive to do compared to just slapping a driver IC. The problem is most likely not the motors, but something else.

They do, and have, the Therac-25 as noting by the GP is a great example, but this kind of thing is still done, even often.

Good points! Do you know of any resource where these kinds of "software will eat hardware (and bite your hand)" are discussed/listed?

It's definitely a buggy device/firmware. There is no way an OS update can cause this (barring some massive Apple bug which is unlikely); more likely the device firmware mishandles some valid standard USB commands that older OSes didn't issue.

In general, it's quite common for USB device firmware to be of extremely poor quality; it'll be tested and bugs fixed until it works with the target OSes and drivers, but no comprehensive testing of whether it can deal with all possible standard request patterns is done.

A big risk with audio hardware is that buggy os drivers might lead to noise being output. One can attempt to detect and block this in hardware, but a compressed EDM track with reduced dynamics can look pretty close to loud noise at some short moments.

Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears.

My experience writing kernel drivers for audio software is that Windows will accept the click sound and then stop processing if the buffer runs dry. OS X used to have issues that it'll continue playing, meaning it'll reinterpret random memory as sound. Not sure if that was fixed in recent Mac versions, as their approach does have memory & performance benefits. But it means that audio driver glitches on Mac can be physically painful for the user.

> Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears.

I experienced one glitch like that while mixing with headphones, it's hard to describe how loud it was, a bang in my ears that made me fall and left me shackling for a few minutes. If you have ever be surprised by headphones at max volume, imagine it's even (way much) louder (because music at max volume is not a full 0db white noise). To this day I now avoid playing with plugins with the headphones and only put them for the final mix/mastering.

The device that can be damaged is a DJ controller with haptic feedback. So it has motors in it, and some kind of audio outputs. If the audio levels get turned to maximum or the motors get sent invalid commands, it could cause the device to damage itself. I’d call it a firmware problem if the motors can be commanded to move too fast, but anyway it may be reason for them to warn their customers. The editorialized hacker news headline makes it look like Big Sur is to blame, but it could easily be written as “Native Instruments Hardware does not fully support Big Sur and could be damaged if run on Big Sur.”

Or, depending on the cause, “Bugs in Native Instruments hardware / drivers can damage their hardware with Big Sur”.

To be fair to the person you're replying to they say:

> I’d call it a firmware problem if the motors can be commanded to move too fast

So it sounds like they agree with you.

(Edit: typo)

It seems that the rule the crowd likes to go with is “last change broke it!”, which is something I don’t like very much.

Yeah, that is an issue of the device IMO. It should prevent itself from being run in a destructive manner so long as the bus itself is in spec (ie no overvoltage, reverse polarity, etc). Unless it is clearly labelled as not to be connected to any system that hasn't been specifically evaluated and qualified by them, this shouldn't be the customers fault.

Also, I initially misread this as National Instruments and imagined a DJ programming in LabView, LMAO.

> Also, I initially misread this as National Instruments and imagined a DJ programming in LabView, LMAO.

This made my day. This is one of the funniest things I have ever read.

I’m not sure why you’re getting downvoted. This is a totally succinct summary of the situation.

Reply on news.ycombinator.com