digikata

When you have many parameters in multiple models with interdependent parameters in feedback cycles the Monte Carlo method lets you sample the space and explore faster. Especially in large scale simulations the execution speed limits exhaustively computing your way through the parameter space.

And because there is likely no simple set gradients to follow, I’d suspect the Markov probabilities let you further navigate local maxima and minima more effectively. Something like a breadcrumb trail of past paths through the forest.

Perhaps only cutting edge makes sense to build new, and once there is increase of cutting edge capacity, older fabs will gain spare capacity to be used for automotive and other industrial users.

You can apply the same principles, but you have to adjust the time coefficients to fit the realities of the supplier.

I think io_uring more or less works as advertised now for the key thing it set out to do, but it removes one bottleneck in a larger system of network processing, so you can switch to io_uring, yet potentially without any other changes, a real world application can hit the next bottleneck due some adjacent architectural decision (or performance regressions as implementations are changed to accommodate an expanding envelope of uses).

And this would have logistical parallels with the just-in-time inventory strategy. which imho has been a maligned in that it does trade off other risks, but it also makes for better supply chain responsiveness (if the buffers are selected correctly on the right items).

Selecting appropriate buffer sizes is critical - a good set of comparisons there is what buffer would one want for streaming a movie vs a buffer for streaming a live video meeting connection.

Manufacturers could alleviate that by planning for battery pack upgrades. Offer customers an upgrade path, transition the old batteries to utility storage until the end of their life and then recycle them.

Yes, but once you have a group picked out, it would be nice if a lot of the other content was hidden and the labels were shown. To do it automatically, is an exercise in space and visual clutter tradeoffs, I'd be as happy to see hiding of any unrelated component, or a schematic subpage, etc. Doing automatically is the hard part, as I know the past the EEs were thoughtful enough to spend some time building topic subpages by hand with maybe minor help w/ their schematic app.

Not meant to be a discouraging comment, as is, it is a nice utility!

The favorite schematics I've worked with on complex embedded parts were where the EE would do breakout pages where the common reference pins were collected together by chip and/or by major subsystem (interface pin blocks, power, bus, peripherals, eth-comms, etc).

In a diagram like this, some side index of topics where a hover would light up multiple pins tagged with that with that topic might be interesting.

Because of the use of UDP, I wonder the variation could end up being wider. There are some large outliers on the chart (though that could be an implementation maturity issue). Also I wonder if the routing environment will continue to be the same in terms of prioritization if http/3 becomes more common. There might be some motivation to slow down http/3 to prioritize traditional udp real-time uses.

While there are other techniques, one thing to think about is how often the analysis/review group is that particular group. In large organizations, if they particular issue being analyzed is with a group that hasn't gotten together before, a more accessible technique like five whys could be easier to use and mediate. If the group regularly gets together to do such analysis, or has a longer range time frame to complete the analysis, more involved techniques could get to deeper work.

And if it’s critical enough, that isn’t just left to chance after the initial design validation. There are continuous supply chain and acceptance testing checks that have to keep being run and managed. This is one reason the costs are higher.

I think the api that allows for more flexibility of implementation underneath is a hierarchical multi tag system with one root of the tag reserved for the existing filesystem, eg. "fs". Paths on /fs/dir/dir/file could serve as definitive storage reference and a way into the existing filesystem apis, while other tag systems can be imposed by the user in parallel trees of tags - all of which refer to the underlying fs tree under their implementations.

That brings back memories of Infocom’s Planetfall where you were a janitor on a space station.

https://en.wikipedia.org/wiki/Planetfall

One could interpret the phrase of great resignation a little more loosely, not as one of people leaving their jobs, but not returning as fast as what is obviously expected. But I agree that the data backed research is lacking in this article. With a little more time they could have done an age breakdown of the participation rate and have a much more interesting article with stronger conclusions.

If you look at a chart of the labor force participation rate, it did drop to a low, and has only partially recovered to a rate last seen in the mid-late 1970s. That is significant. Certainly very different from the rate just previous in 2019. Though to really understand it, I think you might have to pick apart the data among different age ranges.

https://fred.stlouisfed.org/series/CIVPART/

I know little about ship operations - but what is ballasting them when they’re sailing away now without empty containers?

Why isn't the solution to put empty containers back on unloaded ships to be sent away?

BTW for fun reading on operations logistics and identifying and attacking bottlenecks see "The Goal" by Eli Goldratt.

https://en.wikipedia.org/wiki/The_Goal_%28novel%29

I tend to avoid using stash in that fine grained way because branches are cheap in git, and you get a rich set of operations using a local branch to stack up unorganized code changes. Rely on stash on only very quick setting aside of work then returning to it. If I stash and find it needs to live longer than that - I’ll stuff it into a named branch.

That's why I mentioned powering the float if needed ... I suppose it's more of a tethered drone at that point.

Add some steering and if needed power - if you’re lucky you only need to steer to the path with the energy of the vertical ascent.

A small tethered float with accelerometers that ascends along the path of the surfacing submarine.

It’s a matter of some pragmatism. At least their sovereign wealth fund is trying. As much as I wish all nations would take more serious action on the issue, it would seem self defeating for a small nation to step out too early ahead of larger nations in cutting off a major source of revenue. Meanwhile, maybe they’re doing better with the profits for themselves and the world by directing their wealth fund as they are.

https://www.wsj.com/articles/norways-sovereign-wealth-fund-b...

One way to avoid the resource curse is to use the bounty of the resource to develop diversified dependencies/capabilities for a future when that resource runs out or is devalued.

There is a reason project management calls scope-cost-time the iron triangle. It's extremely to bind all three sides tightly unless the estimates are very good, and/or there is significant added buffer to the project (and that really means the cost side is what's stretching to give you extra certainty on the hard scope and time deadlines).

More commonly at most two of the three are tightly constrained, and another side is more free. One can optimize in some directions, but none of the sides are fully independent of each other. I think the best project outcomes I've seen on are ones where only one side is strongly fixed, and the team is in control of the other two aspects.

This was a while ago, but I recall it as one million.

It really depends on who the targeted customers are. I remember inquiring on some TI lines and being told by the rep that unless you’re a customer anticipating 1M+ units, that chip really isn’t available.

Yes, it worked because there as a direct controller to fall back to. But worryingly because two things, it wasn’t a triple failure of the redundant flight computers, is seems to point to a singular failure of the monitoring logic.

The other thing is that the report notes that the aircraft came perilously close to a disaster because it calls out other specific factors could have easily eaten up runway margin leading to a disaster.

The article is long on speculation, but really doesn't have even basic data such as inventory or shipped component levels to do the the most basic verification of the theories.

Are we shipping more chips than even, only demand is allocating unevenly?

Are covid + multiple factory incidents at fault?

Even the cost the stay at the cutting edge facts seem a little suspect for at least some chip markets. e.g. embedded chips such as for automotive use are generally are multiple generations behind fab technology - and really don't need to stay on a cutting edge fab to keep profitably producing for many industrial embedded components.

For non power sensitive embedded parts it makes a lot of sense - at least to the point that the pricing could be worked out with customers that want long term high volume commitments.

Sometimes they're well established and provide very useful characterizations that tie into physical behavior. For examples Reynolds numbers and Mach numbers in aerodynamics are quantities that can tell you immediately what kind of flight dynamics range you're dealing with.