dmsnell

Vapor chambers and heat pipes are exceptional at moving heat from a relatively small part of them to distribute it around the whole.

This is because the heat dumps into a liquid which is concentrated at the heat source, but as soon as it evaporates it fills the volume in which it’s contained. Also it’s because the evaporation process itself sucks out heat at a rate that’s orders of magnitude faster than via conduction, convection, or radiation alone.

They do not cool though. They rely on the fact that the heat source is relatively small and that something else can pull heat out of them fast enough to re-condense the liquid (and since they distribute the heat that cooling can attach anywhere or everywhere — this is like an embarrassingly parallel problem in software).

In a battery pack there is a lot of surface area that gets relatively and evenly hot, and little room to extract it between the cells. This would likely result in even heating around the heat pipe, which would tend to evaporate all of the liquid inside and do nothing but raise its overall temperature after an initial delay.

What it potentially could be used for is to draw heat out of the battery pack and up to some place where better airflow were possible, or for some active cooling system to extract the heat, but there are problems with scaling up like that (in typical heat pipes they manufacture wicking inner layers to draw the water back even against gravity).

At the points they could be used it’s likely significantly cheaper and easier to control some air or liquid cooling loop through the batteries.

Phones are ideal because a tiny little chip is producing almost all of the heat. It’s not even a lot, it’s just in a small area. Temperature goes up when heat can’t escape, so in this case, spreading the heat around even a few square inches can be a major factor in keeping down the temperature of the CPU/GPU.

Contrast this to EV batteries which are huge and produce evenly distributed heat already; there just isn’t the same value when things are big enough to add cooling systems, when cooling systems are necessary anyway, and when the heat pipe or vapor chamber just adds another piece too the system.

When a process crashes, its supervisor restarts it according to some policy. These specify whether to restart the sibling process in their startup order or to only restart the crashed process.

But a supervisor also sets limits, like “10 restarts in a timespan of 1 second.” Once the limits are reached, the supervisor crashes. Supervisors have supervisors.

In this scenario the fault cascades upward through the system, triggering more broad restarts and state-reinitializations until the top-level supervisor crashes and takes the entire system down with it.

An example might bee losing a connection to the database. It’s not an expected fault to fail while querying it, so you let it crash. That kills the web request, but then the web server ends up crashing too because too many requests failed, then a task runner fails for similar reasons. The logger is still reporting all this because it’s a separate process tree, and the top-level app supervisor ends up restarting the entire thing. It shuts everything off, tries to restart the database connection, and if that works everything will continue, but if not, the system crashes completely.

Expected faults are not part of “let it crash.” E.g. if a user supplies a bad file path or network resource. The distinction is subjective and based around the expectations of the given app. Failure to read some asset included in the distribution is both unlikely and unrecoverable, so “let it crash” allows the code to be simpler in the happy path without giving up fault handling or burying errors deeper into the app or data.

The other comment explains this, but I think it can also be viewed differently.

It’s helpful to recognize that the inner script tags are not actual script tags. Yes, once entering a script element, the browser switches parsers and wants to skip everything until a closing script tag appears. The STYLE element, TITLE, TEXTAREA, and a few others do this. Once they chop up the HTML like this they send the contents to the separate inner parser (in this case, the JS engine). SCRIPT is unique due to the legacy behavior^1.

HTML5 specifies these “inner” tags as transitions into escape modes. The entire goal is to allow JavaScript to contain the string “</script>” without it leaking to the outer parser. The early pattern of hiding inside an HTML comment is what determined the escaping mechanism rather than making some special syntax (which today does exist as noted in the post).

The opening script tag inside the comment is actually what triggers the escaping mode, and so it’s less an HTML tag and more some kind of pseudo JS syntax. The inner closing tag is therefore the escaped string value and simultaneously closes the escaped mode.

Consider the use of double quotes inside a string. We have to close the outer quote, but if the inner quote is escaped like `\”` then we don’t have to close it — it’s merely data and not syntax.

There is only one level of nesting, and eight opening tags would still be “closed” by the single closing tag.

^1: (edit) This is one reason HTML and XML (XHTML) are incompatible. The content of SCRIPT and STYLE elements are essentially just bytes. In XML they must be well-formed markup. XML parsers cannot parse HTML.

This was my first submission, and the above comment was what I added to the text box. It wasn’t clear to me what the purpose was, but it seemed like it would want an excerpt. I only discovered after submitting that it created this comment.

I guess people just generally don’t add those?

Still, to help me out, could someone clarify why this was down-voted? I don’t want to mess up again if I did, but I don't understand what that was.

Discussing why parsing HTML SCRIPT elements is so complicated, the history of why it became the way it is, and how to safely and securely embed JSON content inside of a SCRIPT element today.

You understand it correctly: it doesn’t remove any value from fixup; instead it just means you can fixup to whatever and move the commit visually to where you want it — doesn’t have to be the main/trunk branch, and you can do it whenever is convenient.

That’s where I made the comment about not actually running fixup. Instead of claiming to fix a SHA, I leave myself a note like “fix tests” so I can move it appropriately even if I get distracted for a few days

No but I think I saw that it’s a thermal pad, one with comparable thermal transfer characteristics to the high end (non-conductive) pastes.

Yes, that’s correct. All of these measures, of course, stand as a courtesy and are trivial to bypass, as ema notes.

Finding cryptographic-strength measures to identify LLM-generated content is a few orders of magnitude harder than optimistically marking them. Besides, it also relies on the content producer adding those indicators so that can’t be ignored as a major source of missing metadata.

But sometimes lossy mechanisms are still helpful because people who aren’t out with malicious purposes might copy and paste without being aware that the content is generated, while an auditor (be it anyone who inspects one level deeper) can discover in some (most?) cases the source of the content.