s_tec

In Zig's case, it's compile time. An expression like `foo.bar(1, 2)` can only compile if `foo` has a method named `bar` with the right number of arguments. In a duck-typed system, `foo` can be any type of value you like, as long as it "fits" the shape.

In contrast, many languages require you to describe the shape up-front, and then constrain `foo` to implement that shape. For instance, in Rust we would have to write something like `trait Bar { fn bar(a: u32, b: 32); }`, and then say something like `foo: T where T: Bar`, before we're allowed to call the `bar` method.

Both are compile-time safe, but one requires more ceremony (but is more explicit), while the other is simpler (but you might have to guess the requirements).

Probably the pole, footing, and wages for the installation crew.

It seems to be a general principle: If AI is better than you at something, you use it. If AI is worse than you, you don't.

Each time the frontier models get better, I see another wave of AI doubters suddenly become believers. People say things like, "AI couldn't code last year, but now I use it for everything!" Interesting. Now we know how that the person who said this has the coding skills of a Claude Opus 4.5 or whenever the frontier was when they flipped.

Meanwhile, the rest of us keep using AI as simple tools, like the person in the article. I wonder how long it will take before computers can program better than me, and I flip too.

Nifty! I recently bought a RISC-V VisionFive 2 Lite SBC, which required a lot of mucking with firmware and talking to the U-Boot serial console before it would boot Linux for the first time. A tool like this would have been super-handy during that time.

On the other hand, I'm a low-budget hobby user. I like things that are cheap, easy, and hackable. It sounds like your product might be for more-advanced users? Or do all these fancy features stay tucked away until you need them? If you make your product cheaply, that might hurt profit margins, but it might also open up the low-end market. I have so many questions about the business side of this.

But really, I am most curious about the user experience. It's not super-helpful if learning the tool becomes its own project, so I'm hoping it's simple.

Edit: Oh, it's a software project. I thought it was a hardware project. My bad.

This is more of a compressed-air battery than a sand battery, except that the "air" is CO2 and it's "compressed" enough to cause a phase change.

Heat-based energy storage is always going to be inefficient, since it's limited by the Carnot efficiency of turning heat back into electricity. It's always better to store energy mechanically (pumping water, lifting weights, compressing gas), since these are already low-entropy forms of energy, and aren't limited by Carnot's theorem.

I don't know much about this CO2 battery, but I'm guessing the liquid-gas transition occurs under favorable conditions (reasonable temperatures and pressures). The goal is to minimize the amount of heat involved in the process, since all heat is loss (even if they can re-capture it to some extent).

Thermoelectric cooling is pretty inefficient, because the materials need to balance competing requirements:

- Good thermal insulator - Good electrical conductor - Good semiconductor

This is because the hot & cold sides are sandwiched closely together as a PN junction, so once you move heat from one side to the other, it just leaks right back. Mechanical cooling doesn't have this problem, because the hot & cold sides are separated by thin bits of tubing. This makes the thermal leakage a "minor annoyance" in a mechanical system as opposed to "literally the whole problem we're trying to solve" as it is with thermoelectrics.

One work-around is to stack lots & lots of thermoelectric coolers on top of each other. That reduces the temperature difference at each individual PN junction, which in turn lowers the leakage. That's what this team is doing, but using layers that are only a few nanometers thick, so they can fit dozens or hundreds of junctions in a single package.

I'm not an expert, but my understanding is that silicon really loves to be with lithium, which makes it a really energy-dense anode material for batteries. It's also cheap and abundant. The problem is that absorbing lithium causes silicon to mechanically expand, which quickly destroys cell life. The anode physically crumbles away with repeated charging and discharging.

These researchers have found a way to make a silicon electrode like a sponge, which helps with the mechanical problems. Their test cell has pretty "normal" degradation of 80% capacity retention over 1700 cycles, which is incredibly good for silicon. Normally it would be in the 10's or 100's, iirc.

This isn't the charging circuit - that goes in the charger. This circuit is responsible monitoring the state-of-charge (for that little LED bar graph on the front), disconnecting the cells if something goes wrong, and negotiating available current with the tool. It should also be responsible for cell balancing, but it looks like Milwaukee forgot to implement that feature (oops).

The videos at the bottom of the article have most of the details, since those dive into the communications protocols as opposed to the raw schematics.

This is an excellent idea! It would probably make the most sense to perform these adjustments on April 1.

I assumed the post title meant nanometers. Why? Floating-point rounding bugs. A nanometer is about 9e-15 degrees of latitude, which is right about where a double-precision floating point number runs out of digits. So, if a piece of software uses exact `==` equality, it could easily have a bug where two positions 3600 nanometers apart are seen as being different, even though they should be treated as the same.

React Native added auto-linking years ago, which solved the native dependency problems. Just `yarn add` whatever you need, and if it has native code, the the Android side will incorporate it on the next build. On the iOS side, you do have to run `pod install` to lock in the changes, but everything after that is automatic.

Use Expo because you like the extra features it ships with, but not because you have problems with native dependencies. The React Native built-in experience is pretty much perfect to start with.

Each OS process has its own virtual address space, which is why one process cannot read another's memory. The CPU implements these address spaces in hardware, since literally every memory read or write needs to have its address translated from virtual to physical.

The CPU's address translation process relies on tables that the OS sets up. For instance, one table entry might say that the 4K memory chunk with virtual address 0x21000-0x21fff maps to physical address 0xf56e3000, and is both executable and read-only. So yes, the OS sets up the tables, but the hardware implements the protection.

Since memory protection is a hardware feature, the hardware needs to decide how fine-grained the pages are. It's possible to build a CPU with byte-level protection, but this would be crazy-inefficient. Bigger pages mean less translation work, but they can also create more wasted space. Sizes in the 4K-64K range seem to offer good tradeoffs for everyday workloads.

Just because some people do bad things does not mean you get to paint the whole group with those crimes. Imagine if you had said, "Black people are criminals, because a black person robbed the liquor store down the street last week." We all (hopefully) recognize the deep racism in this statement!

Unfortunately, there are parts of the country where this type of racism is acceptable and even common. There as similar attitudes towards Catholics, due to America's history as a predominately protestant country. The formula is the same both way - pick a heinous crime from a few members, blame it on the group as a whole, and feel smug about yourself.

Nah. When I am taking a road trip, the last thing I want to do register an account for some random charging network I'm never going to use again (because I'm in a different part of the world). I just want to pay for my power and move on, just like I can pay for food or anything else on the trip.

When I am at home, I plug my car in and it goes on my monthly power bill. This is where the convenience matters.