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.

What I mean is literally have an assert with incoming data as the parameter:

assert(data_buf[4] < 8);

While your protocol might guarantee that data_buf[4] should always be a value less than 8, you don't use assert() to check it because it aborts the program if the check fails. The proper thing to do is a range check that returns an error for a protocol error (malformed data, etc.).

ZeroMQ literally called assert and any bad data coming in over the wire would cause your app to abort. Insane.

Here is an example bug report:

https://github.com/zeromq/libzmq/issues/186

Keep in mind this was a LONG time ago! So this is not an indictment of the current project!

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.

If you know characteristics of the system, like thermal mass, inertia etc., then coupling feed-forward control along with the PID can help. The idea is that if you know the thermal mass (and you do for a coffee maker's internal elements), then you have a reasonable estimate of how many watts are needed to change the temp of those parts. So, don't make the PID put those watts in, instead just add them separately based on your simple physics model. The PID runs in parallel and corrects all the short-comings of your model.

Maybe it should be based on your driving record? The worst driver you are, the higher the cost to society when you are driving.

It has been like that since the 90s. At Stanford we had a sysadmin track down a warez site to our HP logic analyzer. Everything at Stanford in the 90s had a public IP address (at least in EE).

What is your degree in? Because when I got a PhD in EE it was covered by either being a Research or Teaching Assistant. What school/dept would suggest aiming for anything less than a PhD as horrifying? Most students go that path.

How long until I can make my own movie like Star Wars, but with my story line and my characters? Serious question, does anyone have has insights into this problem?

With as large of economic disturbance we have seen in the last 3 years, you will find examples of almost anything. However, I can assure you as some who was in manufacturing during this period, it was not just price gouging. There were true shortages up and down the supply chain, supplier quotes that used to be good for 30 days were good for 24hrs, and distributors that thought they had plenty of stock found themselves cleaned out by companies panic buying. It was incredibly hard to run a supply chain and for smaller companies, almost impossible to predict the cost of good sold (COGS). If you can't predict the cost to make something, you better raise the price enough to be sure you don't lose money. Many companies had to hire extra people just to track price changes and manage the supply chains. Building anything efficiently was crazy hard. On top of that, in certain markets, people were spending like crazy which made it very hard to stay stocked.

This whole idea of "simply price gouging" is completely inaccurate for many industries.

Doesn't really seem like due process.

Not only a slave to the state, but a slave to private companies. Most electronic payments, including cards and apps are via companies (as opposed to govt). Who wants companies to have more control over their life?

Gentoo is fantastic for building a custom rootfs. I much prefer it to Buildroot or Yocto. Google uses the Gentoo package system for ChromeOS. Using the same portage file allows you to trivially pin the exact version of every installed package and if you cache the downloaded source files (/distfiles), you can reproduce the build anytime in the future.

For example, feed prices and electric prices to heat the coup are generally more predictable than a raging virus.

Because bird flu might be a very unpredictable supply disruption.

I talked to a farmer yesterday who said (at least in the US) it is bird flu. For some reason, the layers seem to have been hit harder than the boilers.

I don't see that distinction being made. The counter argument is things like libraries vs microservices. Those articles ignore the common case that probably is true for 99% of the apps - we live in a service based architecture. The Internet is service based. Everything an app talks to is service based. So quit arguing about it.

Microservices don't address any of the issues I ever faced or people on Hacker News talks about like mixing languages, building code around organizational structure, isolating faults, etc. Microservices are way to granular to address those issues well. The only time I ever wrote a microservice is when I had to wrap some stupid SiteMinder binary apache mod blob.

Also, almost nobody writes a monolith, if they say they have a monolith they are probably lying. Do they have a database? S3? ERP, CRM, blah blah blah. Nobody in their right mind would build microservices, that is nuts unless they have some really special architecture. So can we quit the endless debates about stuff and instead focus on the real issue: how to build robust and maintainable service architectures? How to partition systems properly so you can manage avoiding having conflicting data? Eventually consistent systems, etc.

This is as dumb as the CISC vs RISC debate I lived through in the 90s.

So you embed S3 into your app? Do you embed your ERP system? How about your marketing e-mail system? Your CRM? Do you use an in-process database?

Everyone already has a service based architecture whether they want to admit it or not. The question is the efficiency and granularity of it.

If you interface with any external systems that have data records (ERP, CRM, etc), your database is already spread out. You need to deal with it and be sure you understand the data efficiency and reliability of it.

I don't know what a monolith is that people talk about. Please show me one that doesn't talk to anything else.

In the 90s he would answer Windows programming questions on usenet.