bob1029

> in 2008-2009, 12% of Americans over 40 reported taking a statin, whereas in 2018-2019, that had increased to 35% of Americans.

I wonder about the percentage of Americans who have taken zero prescription drugs this year.

MCP is like Docker or Kubernetes. If you are operating at a certain level of abstraction (low), these tools look like they are getting in the way more than they are helping. For others, they will seem absolutely mandatory. It depends on what your goals and constraints are with the project.

The optical system required to achieve this is infeasible to deploy at the scale required to compensate for concerns like orbital motion at 15+ fps.

It's the 3rd thing mostly.

McKinsey did an article recently that I think helps to paint a good picture about where things are headed

https://www.mckinsey.com/industries/industrials/our-insights...

You can't do a black start from the lowest potential part of the grid anyways. Synchronization isn't the hardest part. You could solve this with GPS and cellular telecommunications. Fault current handling is where things fall apart. You have to start the grid from the top. Fault current has to flow in the right direction or none of the existing equipment will function correctly.

The power walls can help to stabilize islands once they're back online, but they can't meaningfully participate in the initial phase.

I would be much more nervous about a 13+ kWh battery than a natural gas generator.

The generator is generally only risky when in operation. For natural gas units, a normally-closed solenoid keeps the gas off unless the controller actively commands it. A battery is constantly in a state of non zero fire risk when charged.

I wonder how much we could optimize real world agricultural and industrial processes if we reallocated just a tiny fraction of the energy that goes into this game.

There are some mission profiles that simply don't work from orbit. You need too much resolution and frame rate.

https://en.wikipedia.org/wiki/ARGUS-IS

Imagine implementing the above from LEO.

The way the body content animates at page load is pretty annoying.

You can cause a lot of harm by breaking infrastructure. 10 years in prison is a bit extreme for an accident but it obviously has the desired effect. The current penalty in my part of town seems to be $0 and no time behind bars. My fiber optic internet is cut about once every 2-3 months.

I wonder if something in the middle could work. I feel like if you are legally responsible for a construction job and dig into the forbidden spaghetti that a little bit of mandatory community service isn't exactly an extreme response.

I want to know what Singapore's grid operators have been up to. That seems to be the more interesting story based on the data in this article.

I don't see this as being much different from a crane operator or airline pilot.

One of my clients has enforced a policy where a live human user principal must be supplied as a header with any requests outbound from the AI system. The effective policy is that you are completely (100%) responsible for what your agent does on your behalf. The AI system is designed to request confirmation for any potentially destructive actions.

Many forms of maintenance cannot be automated. Especially break fix maintenance.

I feel like we are missing many shades of grey in the middle.

Semi-automation (human in the loop) can still result in a dramatic uplift in productivity. You can't run a combine harvester 100% autonomous but that doesn't stop anyone from trying to get as close to that limit as possible.

> Don't be shy, give them a big task, let them build an entire app, UI and all..

I have found that a willingness to look like a temporary dumbass (primarily to yourself) is the largest predictor of success with pretty much everything.

What are the consequences of asking an LLM for the moon and receiving low earth orbit instead? Who cares if the proverbial rocket explodes on the pad? This is all happening entirely in a computer system completely under your control and likely at relatively low cost. No one else has to find out about your mistakes if you don't want them to.

> They require precision engineering.

A turbocharger (compressor) is already about half of a typical Brayton cycle. The power turbine itself can also be radial in design.

Unless you need insane mass flow rates, radial is probably superior to axial.

Brayton cycle does not necessitate a free flowing jet engine style design.

The trick in this scenario is the fact that you can run it at a constant RPM + load for a reasonably long duration. The cost of warming up a recuperator and other masses is amortized across a dependable schedule each time. The controller can ensure that the turbine (assuming the drive is long enough) will run for a minimum duration given a certain battery charge level.

The reason this stuff didn't work before is because we couldn't run the turbine this way. Now we have viable energy storage technology and can make some of the most difficult variables into constants.

How does it hide tool calls? I have to run those and return the results.

> To further improve fuel efficiency and output, ZR15DDTe engine uses Nissan's unique STARC*2 concept paired with a large turbocharger.

If we are able to consider fixed RPM operation and are willing to endure turbomachinery, I don't know why we wouldn't just go all in on a gas turbine. You can reduce the number of moving parts dramatically and accept a much wider range of fuels.

Being able to engineer everything around a one fixed operating speed makes a huge engineering difference. Reciprocating engines are responsive to load and speed changes, but there are trade offs in many other categories.

You can also make a gas turbine power module quite small relative to the alternatives. Replacing the it at major service intervals could be made economically viable.

> Fourth, if long tool-calling turns still go quiet for longer than you want, have your harness ask for an update

I'm not sure I understand this complexity. In all harnesses I've ever used, tool calls themselves are surfaced to the user as an indication of progress. When the UI/UX around this is engineered well, the user should be able to infer roughly what is going on. Different tools have different ideal presentations. You can't reduce everything to plaintext blobs.

If I absolutely needed intra-turn progress updates, I'd accumulate a separate per-turn transcript and feed it into a cheaper model at deterministic intervals.

One of my clients has an automatic "best practices" AI robot that runs each time you create a PR. It is pure downside. Even the developer responsible for creating it admits as much.

However, for some weird reason it's still in place. This is the part that actually concerns me. Ignoring the bullshit comment is trivial. The quiet and relentless accumulation of entropy is happening everywhere. This is why GitHub crashes at noon every business day.

It is mandatory to wear a bunny suit, mask and goggles in every fab I've been inside of.

They have special security guards who make sure you do the procedure correctly.

Planning largely doesn't work because it's extrapolation. You don't know for sure how that remote system or compiler will react to the proposed change until it actually occurs.

Execution is the answer. All the complex success stories I've seen involved the LLM iteratively probing live data sources with varying filters, throwing code changes at the compiler over and over, or invoking shell commands until it succeeds.

I believe there is a Yoda quote regarding this.

Define "mission critical" and then maybe we can come up with a reasonable estimate.

Higher order thinking is more important and rare.

An aggressive first principles approach often leads otherwise well-intentioned technologists into strategic / ideological dead-ends.

Do we do things because it's the "right thing" to do in the moment, or because of the final outcome that will eventually result?

The most ideal answer is somewhere in the middle. I am far more interested in the total area under the curve than a single instant in time.

In lieu of intentional higher order thinking, simply working backward from your customer on a regular basis will generally accomplish the same outcomes.

Rotary vs fixed wing is more like GPU vs CPU programming. Within each you still need to understand the capabilities of the machine before you can go wide effectively.

We should make developers prove they can use one core responsibility before we hand them 64.

Much like we get pilots comfortable in single engine aircraft before we have them fly around in 747s and AC130s.

2D might never die but modern 3D can be a compelling workflow for producing this kind of content.

The part that gets really painful with 2D sprites is animation. It can be a lot easier to model, rig and animate a 3D character and then place them into a special scene/camera arrangement for automatic capture into a sprite sheet.

Doing these by entirely by hand is a really difficult proposition in the current games economy.

If you are stuck on a ship in a typhoon, iridium is precisely the system you want to be using.

We are currently running nuclear at a capacity factor of around 91% in the US. Solar is somewhere around 24%.

1GW at noon vs 1GW forever. The area under the curve is what matters. Not the peak of the curve.

How much more would you be willing to spend to get 4x the nameplate capacity and to also get it whenever you need it?

The economics of a single plant are irrelevant in comparison to the requirements of the grid that it operates within. If someone could invent a source of power that magically scales exactly with the duck curve in Texas, I guarantee that would fetch a premium on the market, even if other economic characteristics are not competitive.

The solution to nuclear is to standardize the design and deployment process. France has demonstrated it can be done. Perhaps their engineers should be in charge of some new global standards body.