throwaway9870

Add about two zeros to what the West collectively can build.

I literally meant the library would call assert() on incoming data. I am fairly certain that has been removed for a long time, but it can be hard to get past first impressions.

> I have a product with an addressable market of something like 300 to 500 units per year. That puts me in the Defense/Aerospace/Medical area, where unit economics are completely insane.

I have manufactured in that area and while you are not going to be in the mass volume pricing levels, you don't have to be in the defense level either. You just have to build the product with the right trade-offs and design the appropriate manufacturing processes. Few seem to know how to do this.

Edit: let me expand. Don't injection mold if you can avoid it. Do resin castings or thermo-forming, neither require as expensive of tooling. 3D print parts with a good material like PC CF. Metal fabrication is easy and cheap these days. You can get a shop to laser cut, form, insert PEMs and powder coat for very reasonable prices. We are starting to get a lot of machined parts from China. You can source wire harnesses from China also. Do assembly with a small team. Use as much off-the-shelf electronics as possible, but don't be afraid to make small and simple PCBs if it makes your product cheaper and simpler. Leave the complex boards to a vendor initially because while they might seem simple to design, they can be complex to debug and production test properly.

The problem is that it started out as any but stable and reliable. It asserted on received data, which in a network application is a super newbie mistake. When I looked at it, the pub/sub socket would hang forever if the other end interrupted the connection. So the zeromq guide which said "look how easy it is" was only true if you ignored errors. If you are writing network code and ignore errors, well, good luck. That was a long time ago (~10yrs) so if it is better now, good for them. Also, both founders have left the project. One passed from cancer, the other didn't like what he built and started over in C. Not that they can't be replaced, but transitions can be hard and take time.

Because the product engineering isn't as important as the community and organization. I got excited about Firefox when it forked from Netscape, but since then I have been unimpressed.

Rambus is an interesting company. I can't vouch for their crypto offerings, but they have been around since the 90's and at one point pioneered high-speed DRAM interfaces. Lots of what we see in DDR today is based on ideas and concepts they pushed forward in their proprietary interface. Early on, they definitely did innovative work.

IIRC, their interfaces were used in some Sony play-stations and also some Intel systems.

Have you never walked into a store and they said you can't use a CC because their reader is down? It is nice to have a few dollars in your pocket for times like that.

Your comment and mine are basically the same. This is what I call terrible engineering judgement. A random co-worker could review the simple solution without much effort. They could also see the corner cases clearly and verify the tests cover them. With this code, not so much. It seems like a lot of work to write slower, more complex, harder to test and harder to review code.

I don't understand. There are 7 suffixes, can't you pick the right one with binary search? That would be 3 comparisons. Or just do it the dumb way and have 6 comparisons. How are two log() calls, one pow() call and ceil() better than just doing it the dumb way? The bug being described is a perfect example of trying to be too clever.

Depending on how you define "randomly", you might have just decided no more phones, laptops, etc. Bad batteries can sneak into even the best supply chains and cause fires.

I don't like this. I recently sold some networking equipment to somebody for a bit more than this amount and asked for cash. Made the whole transaction simple. Things like this just keep taking power from the people and moving it into the government and private companies.

I think you are confusing terms. You are saying latency, but I think you mean the time constant of the poles / zeros. When one speaks of latency in a control system, they general mean a real time delay, like a digital processing delay, communication delay, etc. When you speak of something having low-bandwidth, such as due to the thermal mass and heating element you are describing, then one would say it has a long time constant. I have never seen these systems any harder to implement with a PID provided you select the proper terms to keep it stable. If it is just a linear PID, it is going to need to be a slow loop in this case.

A couple days ago there was a thread on Hacker News that devolved into a discussion of what a comp-sci student learns in school that they can't learn by themselves. Control systems are a good example of something that is good to have a basic background in and can be hard to learn by yourself. I think it much easier to learn this topic in school because you have an instructor to answer questions and are surrounded by other students who you can discuss the topic with to help you gain intuition about all the math.

Yes and no. PID loops are linear systems and don't understand ramp-up and ramp-down times. They understand poles and zeros. So normally you would speak of time constants and bandwidths rather than ramp (slew) rates. This is not just semantics, they function differently. However is not unusual to add non-linear constraints on top of of linear control loop so you end up with a hybrid control system.