curriculum

Give it some spin with your index finger. Imagine putting a coin between your index finger and thumb, heads side up, resting on your middle finger below — not too different than how most people start a coin flip. With your index finger, rotate the coin in its plane, so that it stays “heads up” but the head is rotating. Now try doing this and simultaneously flipping the coin by flicking it with your thumb at a point on the bottom, close to the edge. If you do it right, you’ll impart a spin. If you impart a modest spin, the coin will never actually flip over, but will just wobble, and will therefore land heads up. An observer will likely not know what you did, because it is hard for the eye to tell the difference between a flip and a wobble at high speeds.

I'm not sure if avoiding Home Manager is the right choice for everyone, but it worked well for me.

Home Manager isn't necessary for declarative management of the user environment -- Nix flakes can do this, too. A long time ago, I kept a single `flake.nix` in my home directory describing the packages that each of my machines needed, and ran `nix profile install .#packages.<machine>` to install them into my user profile. By doing things this way, I learned a lot about writing flakes, and this transferred to other places I used Nix.

What this doesn't do that Home Manager does is dotfile management, but that's actually why I avoided HM originally. First, HM's approach is a bit clunky for my taste: each change to the configuration must be followed by running `home-manager switch` for the changes to take effect. I found this to slow down the edit-and-test loop when making changes to my shell config, etc. Second, the idea of doing all configuration in the same Nix language is cool, but most of the documentation found online about configuring, etc., `git`, will refer to the tool's usual method of configuration.

So instead, I made a quick Python script that manages package installation with Nix, and dotfile management with GNU Stow. The dotfiles and Nix configuration all go into the same git repository in my home directory, so they are tracked together. I've been using this approach to manage several machines for a few years now, and it's been more than sufficient for my needs.

> Seems like a policy set with priorities other then environmental protections.

There are definitely other non-environmental considerations at play, the largest being that the increasing number of home solar installations has reduced revenue streams for utility companies, while at the same time their costs have increased due to grid maintenance and wildfire prevention projects (and lawsuit payouts). Most houses with solar are still heavy users of the grid, yet they pay very little towards its upkeep. This pushes the costs onto people without solar, who tend to be renters or low income households.

> Energy cost has long been viewed as a means to constrain consumption. This new approach seems to undermine that approach given the reduced cost per volume.

The idea that electricity consumption must be constrained makes sense when the electricity is generated by fossil fuels -- replacing a gas furnace with an electric heat pump when the electricity is made by burning coal is not a big improvement. But we're entering a world where most of the electricity is generated by clean solar, and constraining usage doesn't reduce emissions quite as much. In this world, a heat pump powered by solar is a real improvement over a gas furnace, environmentally-speaking. But a heat pump only beats a gas furnace in terms of cost to operate if the price of electricity comes down relative to the price of gas.

From that perspective, removing constraints on electricity usage is not a bug, but a feature.

I think the idea is that California has plenty of solar generation during the day (or is on track to have plenty); what it needs is storage for when the sun isn’t shining.

The new NEM (the Net Billing Tariff) shifts the incentives away from solar generation (which the utilities have a lot of) and towards energy storage. I am in the market for solar right now, and I’ve been running the numbers. Whereas I would have had the greatest ROI with a large solar panel array under the last NEM, I now get the largest ROI with a small solar array + a battery.

I can’t say that my ROI will be the same under NEM 3.0 as it was in the old NEM, but solar is not suddenly a bad investment, as some might claim. A small solar + battery setup will pay for itself in 5 years in my situation. A battery alone (no solar panels) pays for itself within a decade, since you can buy energy for “cheap” during super off peak and store it for use during peak hours, pinning your electricity costs to the lowest of the day.

This is all with existing rates. The upcoming shift to an Income Graduated Fixed Fee will likely come with reduced per-kilowatt-hour rates, which will reduce the ROI for home solar and batteries.

Not quite. Right now, (most) California residential electric bills are entirely volumetric, meaning that you pay for what you use — if you use zero, you pay (close to) zero. Under the new system, everyone’s bill will instead have a sizable fixed component (determined by household income) for being connected to the grid, and a volumetric component (determined by the amount that you use). The new price per kilowatt hour will be smaller than the existing rates.

My claim wasn't that an Income Graduated Fixed Charge would make your electric bill go down from what it currently is -- it could very well go up.

My claim is that, assuming an IGFC is implemented and the marginal cost of electricity goes down considerably, then a heat pump becomes cheaper to operate. You'll be paying the same fixed cost to be connected to the grid, whether you have a gas furnace or an electric heat pump. It might just be that the newly-lowered electric rates finally make a heat pump more cost-effective than a gas furnace.

California is moving towards a system which would introduce a monthly fixed cost based on your income, while simultaneously decreasing the cost of electricity per kWh (see: AB 205). Heat pumps become more attractive after such a change.

Along the same lines, asking

> How many words are in the sentence "This is a test of artificial intelligence"?

yields an answer of:

> There are 8 words in the sentence "This is a test of artificial intelligence."

(There are 7).

I think what you're referring to in your last paragraph is a CEREC crown, but it's not always cheaper. In my case, my insurance covers a lab-made crown with a $100 copay. It takes a few days to be made, so it's slightly inconvenient. Same-day CEREC crowns aren't covered by my insurance, and cost around $500-$800 at the dentists I went to.

I discovered this last year when I went to a new dentist and they recommended two CEREC crowns and a laser gum cleaning at a total cost of around $2000. This was surprising, because I thought my dental insurance was pretty good. Turns out, it is: the dentist was just electing to use more expensive methods that weren't covered by insurance and failed to tell me about the options. I did some research later and found that the laser cleaning was not demonstrably better than the traditional approach in terms of outcomes (though I think the gums are supposed to heal faster) and was not endorsed by the periodontist professional society. I saw some sources which said that the same-day CEREC crown is actually worse than the lab-made crown in terms of fit and durability.

Indeed, and this leads to another important interpretation: matrix multiplication is function evaluation.

Arbitrary functions which take in vectors and output vectors can be very complex and thus difficult to reason about. A useful simplifying assumption is that of linearity: that f applied to a linear combination is just a linear combination of f applied to each piece of the combination separately. Linear algebra, broadly speaking, is the study of functions of this kind and the properties that emerge from making the linearity assumption.

It turns out that, if we assume a function f is linear, all of the information about that function is contained in what it does to a set of basis vectors. We can in essence "encode" the function by a table of numbers (a matrix), where the kth column contains the result of f applied to the kth basis vector. In this way, given a basis, any linear transformation f has a matrix A which compactly represents it.

Since f is linear, to compute f(v) I could write v in my chosen basis then apply f to each basis vector and recombine. Alternatively, I could write the matrix A representing f in that basis, and then multiply Av. The two are equivalent: that is, Av = f(v). And so matrix-vector multiplication is "just" evaluating the function f.

It should be pointed out that you can install the nix package manager in Arch (or whatever other Linux, or macOS, etc.), so you can try out nix's declarative package management without actually switching to NixOS.

In my opinion the real downside of using <count>j and <count>k to move isn't the counting part, it's the fact that <count>k isn't a jump. That means it doesn't go into the jump list.

Sure, you can make a hotkey to launch any editor, but not every editor is as "pathologically configurable" as vim. The combination of vim being terminal-based, highly-configurable, and lightweight makes it nice to use in a variety of contexts.

Not yet! I just moved to 0.5 this weekend. But thanks for the link!