digikata

I always wished that the acoustic refrigeration tech ended up working out better with wider adoption.

I’ve worked on multiple projects where, at the early prototype stage, we limped along with off the shelf generic heatsinks, or even no heatsinks, for a phase or two because for some reason, it was long lead or high expense or low priority to fit a custom high performance heatsink. It sometimes seems like thermal work is as eschewed by electronic engineers as mechanical engineers often avoid HVAC.

The thought occurred to me that the language development process for Rust and Python (and I’m sure others) encourage a variation of this document first process.

Many high level engineers that I’ve been impressed working with are very good at merging in a technical memo or brief, often at the start or early in the process.

I’ve seen this claimed for multiple job pre-vetting sites and am not convinced it does anything than add an extra layer of test interviews.

It would be neat if you could print in some of the jellybean components - even just covering a range of resistors would be interesting.

Pcb manufacture has long used screen printing techniques to apply solder paste and label stencils. The new part here is using it to apply things like conductive ink traces.

I would think there are different electrical characteristics to account for - as the article alludes to, but also strength of bond to the substrate (esp for components like connectors).

There's a large set of different algorithms with a sliding window. Another interesting one is the Rabin fingerprint. This kind of chunking is often used in storage file systems w/ deduplication and snapshot features.

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

NVMe is built on PCIe, so latency wise, they will be limited by the PCIe latency (roughly an order of magnitude slower than the memory bus though pcie 5 may be smaller than that) + media latency. Throughput wise, they are limited by the number of PCIe lanes that the controller supports, and the system it plugs into has been sized to allocate.

The generation of flash chip in the drive can make a major difference there, as well as fill, the wear of the drive and it’s internal firmware architecture. The makers also target different tiers of performance with different model lines too and that can be a huge difference.

From what I’ve seen a relatively simple radar is what many automakers are using as the main sensor for AEB. You can see them on the front grille, usually a small rectangular patch in the plastic about the size of paperback book.

Though those have had their problems too. Obviously easier for them to detect other vehicles but harder for pedestrians.

I think this is using a less extreme Wing in Ground Effect, different technique than a hovercraft.

https://en.wikipedia.org/wiki/Ground-effect_vehicle

Kia Niro, comes in Hybrid, Plug-in/Hybrid, or EV variants

In addition to the other good comments regarding medical/automotive overlap, is that often those chip lines have long lifecycle commitments built into them - ie. we promise to make this set of parts for at least 10 years. For both both of those customer areas, not having to redesign your boards and recertify devices on an external timeline is of value.

There is a reason penny wise and pound foolish is an enduring saying.

Someone with the right background and contacts should put it together, I think the smart move there is to not only plan on selling chips into regular markets, but to get into talks with customers to become a guaranteed supplier that derisks correlated shortages from other sources.

I've seen that in the scope of the technology life-cycle.

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

Once it's taken off sometimes there is reference to the the manufacturing s-curve. That would be on the Wikipedia chart, going from when the R&D has traction to where increasing scaling increases volume and reduces costs of the product.

Wait for a teardown and select a place to drill your own hole? But yes, a surprising lack of design forethought.

I've been using iCatcher on ios for years now. It has all the things you mention but also a nice set of sorting logic to choose from as well as other per-podcast options like prioritization and number of episodes to download/display etc.

Logistics analysis probably has a lot of crossover w/ queuing theory.

How big a buffer should one maintain if you want the user to be able to keep consuming a video stream for an up to x second packet loss window vs how big an inventory of parts carry in order to keep a production line going given an interruption of x months. Only the physical product has a harder time substituting some sources than others so optimize inventory/buffers on an individual per part basis.

Toyota was one of the creators of Just in Time manufacturing, and they planned for this particular supply chain interruption.

https://jalopnik.com/toyota-prepared-for-the-chip-shortage-y...

rustup target install <arch> e.g. armv7-unknown-linux-gnueabi

cargo build --target <arch>

You can also set it by default:

https://stackoverflow.com/questions/49453571/how-can-i-set-d...

I was recalling this paper characterizing loss of system drive performance due to environmental vibrations (though I'm sure there are others).

https://www.usenix.org/legacy/events/sustainit10/tech/full_p...

A reduction in floor and building vibration might have contributed too?

I wonder if there are intermediary steps to getting to better at causality in ML. Causality is an abstraction of a whole set of a lot of different levels of problems.

In terms of concrete problems earlier than causality. E.g. toddlers I think get object permanence before causality, and I think ML might struggle with that too.

Edit: then the next interesting thing after permanence is maybe obj path prediction, then you have an interesting basis for some level of causality inference because you have a prediction and some set of conditions that might disrupt the prediction.

Wouldn't one of the "obscurity" features in this case be how few messages were encrypted with the cipher? If there were a larger database of encrypted messages, it may have been more susceptible.

Not Toyota, but I don't know how large their mitigation buffer was set to. Seems like they took the logistical risk analysis more seriously than other makers.

https://www.autoblog.com/2021/03/09/toyota-how-it-avoided-se...

This brings back memories of visiting the Computer game museum in Berlin. It’s a small museum dedicated to early computer games and also has preserved a number of early demos. Worth a visit if you ever find yourself with a couple hours of free time there. Oh they also have a working giant Atari and NES controller.

https://www.computerspielemuseum.de

https://www.tripadvisor.com/Attraction_Review-g187323-d20352...

Not that it isn't an underdeveloped area, but the needs of the streaming cases are different. One key difference is if there is no feedback/interaction on the livestream, then there could easily be a relatively long time buffer that would not be noticed. Vs moving a mouse pointer around on a desktop where it would get annoying at a few hundred milliseconds. It also leads to differences in how the encoders and decoders need to be applied.

Zola has instructions for how to set up git -> site update automation to Netlify or Vercel through GitHub or GitLab. I setup that process to try that out on both for a website for a local org I volunteer for and it was quick to get going. Not sure how easy a non-technical user might find updates though.

Not foss, but for basic solid modeling CAD, I've had a nice experience w/ OnShape