nrclark

Agreed with this sentiment, but with one minor modification: use a Makefile instead. Recipes are still chunks of shell, and they don’t need to produce or consume any files if you want to keep it all task-based. You get tab-completion, parallelism, a DAG, and the ability to start anywhere on the task graph that you want.

It’s possible to do all of this with a pure shell script, but then you’re probably reimplementing some or all of the list above.

I feel like submodules are one of Git's most misused features. They're intended as a method of pinning read-only upstream Git dependencies. And when used for that purpose, they're good at what they do.

I think that people mostly get a bad taste in their mouths because they try to use submodules for building multi-repo workspaces where a developer might need to commit in some/all of the repos. They're a bad fit for that problem, but it's mostly because that's not what they were designed to do.

I'd love to see the jj team tackle case #2, personally. I bet they'd do a pretty good job of it.

Does Claude Code use a different model then Claude.ai? Because Sonnet 4 and Opus 4 routinely get things wrong for me. Both of them have sent me on wild goose chases, where they confidently claimed "X is happening" about my code but were 100% wrong. They also hallucinated APIs, and just got a lot of details wrong in general.

The problem-space I was exploring was libusb and Python, and I used ChatGPT and also Claude.ai to help debug some issues and flesh out some skeleton code. Claude's output was almost universally wrong. ChatGPT got a few things wrong, but was in general a lot closer to the truth.

AI might be coming for our jobs eventually, but it won't be Claude.ai.

There's a distinction to make between Jewish people and Israel.

Jewish people are fine. The Israeli genocide of Gaza is not.

citation needed

It's also worth noting - the Bible isn't a single book, and it never was. It's 66 or 73 separate books (depending on the flavor of Christianity), bound together in a single binding. Much more of an anthology than a single book. The books were separated in time, authorship, culture, and even language. Never intended to be taken together as a single document.

The landing team's job is to "land" patches into upstream. They take Qualcomm code and spin straw into gold until it's eventually good enough to contribute to projects like the Linux kernel.

Having read a lot of Qualcomm code myself, I don't envy their job.

TIL. Thanks for this context!

There's a certain irony in the idea that Hawaii has interstates, given that it's an archipelago. It's great that H1, H2, and H3 exist, and Hawaii deserves the same road funding as any other state. But there's some lesson about naming conventions, or emergent properties, or maybe something else to be had here for sure.

I'm not sure about that. For whatever reason, I've noticed that my brain has a hard time holding onto ideas from LLM-written documentation. Maybe because LLMs generate the mathematically lowest-energy thing that they can.

I'd take poor grammar and interesting ideas over clear grammar devoid of real content any day of the week.

When talking with recruiters, I usually decline to state the first number politely - saying something like "salary isn't the only reason why I'd take a job, and I always look at the whole package as well as the role. I'm sure your offer will be competitive."

On forms where I have to put a range, I put $1.00.

I just gave that a read. Good doc overall. There are a few items I disagree with:

- Cargo-culted use of -o pipefail. Pipefail has its uses, but it breaks one of the most common things people do in a pipeline: filter the output with grep. Add it on a per-recipe basis instead.

- Marking non-file targets as .PHONY. This is strictly correct, but it's usually not necessary. I think it adds unneeded verbosity to the Makefile, especially if you have a lot of targets. Better to add it on an as-needed basis IMO.

- Recipes with multiple output files. Use of dummyfiles/flagfiles used to be the standard if a pattern-rule wasn't the right fit. But as of GNU Make 4.3 (shipping in Ubuntu 22.04 LTS), there is native support for grouped targets. Check it out here: https://www.gnu.org/software/make/manual/html_node/Multiple-...

Yes. They were approved for C++20 with no working reference implementation. This was done over objections from representatives from every compiler and build system. 5 years later they're still not widely (or fully) implemented.

They're impossible to implement in Make, which is without exaggeration the world's most widely-used build tool. Even CMake has had a very difficult time implementing them. They break most methods for incremental builds, and mean that a compiler is needed just to determine staleness. They also make fully parallelized compilation impossible, because dependencies can't be fully resolved by the build system.

Modules are a disaster tbh.

Agreed if you're looking at it through the lens of portable software that you plan to distribute. Automake generates portable Makefiles for a reason.

But there's another huge category: people who are automating something that's not open-source. Maybe it stays within the walls of their company, where it's totally fine to say "build machines will always be Ubuntu" or whatever other environment their company prefers.

GNU Make has a ton of powerful features, and it makes sense to take advantage of them if you know that GNU Make will always be the one you use.

How do those stack up against lp_solve (https://lpsolve.sourceforge.net/5.5/index.htm)?

Understood. I'm actually thinking about a product design for an aarch64-based industrial controller.

I'd want to run all of the machine interfaces directly on Linux, but am interested in using Android for everything user-facing. Could I get away with running Cuttlefish in KVM (on an aarch64 SOC) and get OK performance? I'm thinking that it could be a good way to keep the important stuff isolated.

A question for any Android folks in the thread: how performant is Cuttlefish? Would I get good performance if I ran it in KVM on something like a Raspberry Pi 5? I've been thinking about a design that runs some robotic services natively, with a user-facing Android inside of a resource-constrained VM.

I'd have expected this to need a hashbang (#!/bin/sh) at the beginning. Why doesn't it?

I did a lot of chores growing up. Looking back, X>x was true for the first few months of each new chore; but X died down to zero as time went on.

Alcohol stoves can be very fast. I've done a bunch of hikes using one of those double-walled cat can stoves, and it works great. Really pumps out the heat. Very reliable, and almost as fast as my canister stove.

I've taken this stove backpacking lots of times: https://zenstoves.net/CatCanStove.htm

it's been very reliable, lightweight, and works in cold weather. Fuel is cheap and a lot more environmentally friendly than disposable cannisters.

Plus, it's easy to make and works great as a project for ~10-year old kids. You need a windscreen and a pot stand with it (those are both easy to build), just like you would with any other small burner stove.

The one change I made to that stove's design was that I used a little bit of JB Weld to help keep the inside can in-place. Then I put the lid back on the outside can and JB Welded it on. The result was a very durable, lightweight stove that works great.

I work in embedded systems. In that space, it's pretty common to need some vendor-provided tool that's Windows-only. I often need to automate that tool, maybe as part of a CI/CD pipeline or something.

If I were to do it with a Windows VM, I'd need to:

  1. Create the VM image and figure out how to build/deploy it.
  2. Sort out the Windows licensing concerns.
  3. Figure out how to launch my tool (maybe put an SSH server into the VM).
  4. Figure out how to share the filesystem (maybe rsync-on-SSH? Or an SMB fileshare?).

If I do it with Wine instead, all I need to do is:

  1. Install some pinned version of Wine.
  2. Install my tool into Wine.
  3. Run it directly.

In my mind, I almost feel like the opposite is true. Wine is getting better and better, especially with the amount of resources that Valve is putting into it.

If you want a stable, repeatable way to wrangle a Windows tool: Wine is it. It's easy to deploy and repeat, requires no licenses, and has consistent behavior every time (unless you upgrade your Wine version or something). Great integration with Linux. No Windows Updates are going to come in and wreck your systems. No licensing, no IT issues, no active directory requirements, no forced reboots.

Democracy is two wolves and a sheep deciding what to have for lunch.

I won't defend these tariffs, or their rollout. But I will say that our dependence on Chinese manufacturing (and engineering, these days) is not good for our nation.

Free trade combined with cheap labor led to a massive loss of national capability. We outsourced 75% of the supply chain for electronics, and provided decades of free training to foreign companies. Then we pulled a surprised mug when those same companies decided that they don't need us any more.

As a parent of young kids, I'm also keenly aware of how much random plastic garbage we import - just to throw it away after maybe one use. Party favors are a big one. Families are drowning in low-cost, low-quality products that wind up in a landfill. Free trade created this situation, and I don't think it's good for anybody except importers and factory owners.

I don't know what the solution is, and the current tariffs clearly aren't it. But free trade with China hasn't exactly been great for the US in a longterm sense, and we shouldn't pretend otherwise just because we're getting cheap consumer goods.

I don't think you're being overdramatic. At this point, I'd give 50/50 odds that Trump will install himself as a Putin-style dictator (if we're not already there). "Elections" will happen, but the outcome will always be the same at the national level.

The first rule of dealing is "don't get high on your own supply".

> We found that the the Great Flood in the book of Genesis existed

Floods are certainly a thing that happens in nature - especially to the flood plains that surrounded large rivers like the Euphrates before dams were a thing.

Are you referring to a specific event? Or just floods in general?

what is unconstitutional about a wealth tax?