fleventynine

My argument is that the grid has to be designed to handle the load from cloudy weather that lasts over a week. Nobody can afford a battery system that can last that long. So the rooftop-solar enthusiasts either need to install and maintain a backup gas generator on their property (and disconnect from the grid), or pay their fair portion to maintain the grid so it can provide power to them during such weather.

As it is provisioned for peak demand, the grid will cost roughly the same to maintain as it does today, even if people only use it 10 days a year. In this world, there aren't many options:

1. Charge a fixed fee to everyone hooked up to cover the cost of maintenance and repair (and servicing any bonds).

2. Don't charge a fixed fee, but increase the electricy rate by 36x (365/10) so the overall income is the same as before. This will bankrupt those few folks who can't afford their own solar-battery system (or don't have sunlight reaching their rooftop).

3. Have the government maintain the grid and generation infrastructure, similar to roads. This is very similar to option 1 (especially the means-tested version of #1), except the money is collected via taxes instead of a bill from the utility.

4. Let the grid fail by not maintaining it. Everyone must maintain their own self-generation infrastructure, with no economies of scale.

I don't think options 2 or 4 are wise...

Imagine a world where everyone in the state has an overbuilt solar battery system installed, but still relies on the grid those few times a year with extended cloud cover. It would cost a ton of money to maintain all that (mostly unused) infrastructure, and somebody needs to pay for it...

If you don't want to pay for the convenience of having on-demand power whenever you need it, disconnect from the grid.

Now whether these fees should be income-based is another debate, but some sort of flat connection fee makes a lot of sense in the future...

NEM 2.0 pays solar homeowners a rate that is far above the market rate of instantaneous power (paid via an unsustainable, regressive "tax" on non-solar households paying astronomical rates). Roof solar panels are far less economically efficient than dedicated solar installations in the desert. I agree that subsidizing solar plant construction was a good idea, but NEM 2.0 was bad policy.

Poor folks don't have the capital to install solar or upgrade the insulation on their houses, and (in California) typically live in a much more hostile climate. They need to consume significant energy to live and end up paying for a significant portion of the NEM 2.0 "subsidies" as part of their power bill.

Government subsidies could come from the general revenue of the state, which is mostly fed by progressive taxes (poor folks contribute much less money than rich folks). It would be better to subsidize green energy directly from general revenues.

They need to be careful with how high these charges are. Replacing their grid connection with an oversized solar-battery system combined with a propane backup generator might be more attractive to rich folks.

Once home batteries are available in the $200/kWh price range, the California home solar market will come back.

NEM 2.0 was a ridiculous transfer of wealth to rich households who could afford panels, and I'm glad it's over.

If you're generating machine code at runtime (JIT), you can have memory bugs no matter what language your JIT is written in.

We need more housing, and we needed it yesterday. Ugly is better than nothing. Folks that care about aesthetic quality over quantity are part of the problem.

A reddit thread with anecdotes from EV owners during this cold snap:

https://www.reddit.com/r/Calgary/comments/194yg8x/how_are_yo...

General consensus was that while some models lost ~40% of their range, the cars were more than adequate for getting around the city, even when parked on the street overnight.

Likewise. A friend was almost killed a few years back by a counterfeit SSR purchased on Amazon. I would love to see them take some legal responsibility for the lethal garbage they let onto their platform.

When the news stops being consistent with my lived experience, I stop paying attention.

> if I spin up a VM with networking disabled I feel pretty confident I can run anything safely, even malware is not going to escape.

You are putting too much faith in your VM monitor to keep you safe. There's a lot of attack surface in (for example) QEMU peripherals, and there's plenty of examples of VM escape [1]. CrosVM is probably the only publicly available VMM I'd be willing to trust, and even then I'd be nervous running state-sponsored malware on a machine with important data.

[1] https://www.google.com/search?q=qemu+vm+escape

> Let's remove 20% due to 8b/10 encoding

Thunderbolt 3 uses 64b/66b encoding (unlike display port 1.2 alt mode), so there's more bandwidth left over for non-display protocols.

I use Rust for bare-metal development (no libc, no allocator, no panic, 32k size limit), and it is comparable to C and C++ for that use-case. The project is 99.5% Rust with a bit of assembly glue for startup/interrupt handlers.

Modern GCC is also primarily written in C++, and has had C++ deps since 2013:

https://github.com/gcc-mirror/gcc/blob/master/gcc/input.cc

It can be safe if the language provides a mechanism to tell the compiler that borrow_field1() and borrow_field2() will never mutably borrow the same fields. This would be part of the public API of those functions, and compilation would fail if the implementations were changed to borrow the same fields.

This is the biggest pain-point of the language. We need a solution.

Why would you want to run 2.5G or 5G over fiber? 10G fiber transceivers are dirt cheap and barely use any power. It's the 10G copper transceivers that have thermal/power issues...

I don't think permanently wiring high-speed twisted-pair makes much economic sense:

CAT8: $0.55 / foot

Max speed; 40 Gbit

Max length: 30m

(https://www.monoprice.com/product?p_id=42957):

---

2 strand OS2 single-mode fiber: $0.09 / foot

Max speed: 800 Gbit (today; theoretical max speed is much higher)

Max length: >10km

(https://www.cablewholesale.com/products/bulk-cable/fiber-opt...):

OS2 has been around for decades, and will be more than good enough for the next several decades.

There's a lot to like about Zig, especially related to metaprogramming. Unfortunately, bulletproof memory safety is table stakes for a modern language. Without a garbage collector or borrow checker, Zig is DOA for any use case that involves untrusted data.

Maybe there's a few niches (single player games?) that don't need memory safety...

Among 32-bit microcontroller-class architectures, modern toolchain support for rv32imc is second only to armv7m IMHO. Nobody wants to maintain support for any other vendor-specific ISAs.

Embedding binary data should be part of the language/toolchain, not the operating system. For example, include_bytes!() in Rust.

Grumpy NIMBYs. The state's ADU laws override local zoning requirements such as minimum setbacks, allowing their neighbors to build "horrible monstrosities" that "violate the spirit of the community".

I agree with this statement if my data structures map cleanly to Rust's preferred single-ownership, which most problems in my domain do.

Sometimes I do run across problems that are difficult to express in Rust without resorting to interior mutability, and it can slow me down to figure out the best way to model my data.

Then choose from one of the countless garbage-collected languages with sum types and a runtime; Rust is successful because it's offering us systems programmers something unique.

Many of the safety benefits of Rust disappear once you start JITing machine code and jumping to it...

IMHO, using an vector index as a pointer should be a last resort (as an alternative to unsafe). Although it's memory safe, you still have many of the traditional issues like stale pointers / use-after-free, plus you also have the cost of a bounds-check on every access and making sure you use your stored indexes with the correct container instance. If you can solve your problem by using safe code with lifetimes, that should be preferred.

> Even without any soundness issues or bugs or security flaws, people can just plain write malicious code. Rust prevents a lot of common _mistakes_, but people can also use it to write completely "safe" worms that are guaranteed not to have use-after-free errors, data races and unexpected panics.

The idea here is that if the "evil crate" is prevented by the compiler to call out into any os functionality or use unsafe, the worst it can do is return bogus values, mutate anything it has a &mut reference to, and leak heap memory. And if the toolchain were perfect, that might be achievable.

This was the promise that Java Applets made, which wasn't achievable due to the JVM being too bug-prone.

It would be nice to see some sort of sandboxing for these. I would love it if cargo had a mechanism to run all build actions for a crate inside a firecracker vm.

That said, most build systems can access everything the user has access to, so it's not really a regression from the industry standard.

And Rust's typesystem on its own isn't enough to protect against malicious crates, even if you ban all unsafe code, procedural macros, build.rs, and filesystem/network APIs. Several soundness issues were found in previous versions of the standard library that allow a malicious crate to take advantage of undefined behavior to run arbitrary machine code. It seems likely to me that there are similar unknown issues lurking in today's standard library or compiler.

If you care about security, you have to audit your dependencies very carefully, no matter what language you are using.

It will "work". It won't be as fast and precise as the JVM.