imtringued

I don't see how the monopoly argument makes sense considering everyone and their dog is building a rocket startup these days.

I mean Falcon 9 is dead simply because the Neutron rocket will make it obsolete for small sat launches.

And obviously Falcon 9 was never really meant to be a moon rocket either so that is where New Glenn comes in.

Starship was always meant to be a Starlink launcher and everything else was a bonus.

Well, I have some bad news. Starship isn't following the Falcon 9 development philosophy.

Starship is literally a boondoggle project by a space company that was the new kid on the block and now has the same hubris as the old kids on the block.

Nothing about the Starship development process is remotely close or has any similarity to Falcon 9.

Starship SpaceX is "old space".

The Falcon 9 philosophy was as follows: Make it work, then push the envelope and learn from the failures.

The Starship philosophy: Let's set ourselves ambitious goals that push the envelope from the start. Partial success is a failure. The cathedral must be finished before we can launch the first customer payload.

Hint: SpaceX doesn't want to cannibalize their cash cow Falcon 9. Typical old company thinking.

If you have a file in your repository that is not safe to run you have bigger problems than your development system getting compromised.

What I mean by this is that if you restrict python execution to the entry point of your software and then Claude wants to run a command anyway so it threads it through the main.py script, you are no longer running something that is contained to your local development environment.

But when you think about it, what exactly prevents Claude from doing that anyway?

Claude could add malware into your project directly.

So the case where you say it doesn't matter which python script it can execute, actually does matter. Restricting python execution to a subset of all files buys you security.

The next step would be to get Claude to stop adding malware to your software, which it hopefully already does not do.

So basically you gave up?

Nothing more comfortable than having to use git commits and branching just for telling the agent which lines it messed up instead of simply not writing the garbage in the first place.

I don't use claude code but whenever codex uses a command to write code I do not get the diff of the patch for manual approval so I just straight up reject it.

Ok but the problem with this argument is that you could come up with a hypothetical EV that can store enough energy to last a year and then take a year to charge.

And yet nothing prevents you from driving daily.

What matters is how much range you drive and recharge, not how big your battery is.

There are many hours in a day and EVs are pretty efficient. You might struggle if your goal is to drive 200km per day but if all you want is to drive to work or go shopping, you'll be fine.

No, their point is wrong either way and there is no way to steel man it without saying the comment is extremely poorly articulated.

30kWh is 1.25kW for 24 hours or 30kW for one hour.

30kW every hour means 720kWh per day. 30kW all day is also 720kWh per day.

The comment is nonsense.

The only way you can steel man it is by saying he isn't concerned about the 1.25kW, he is concerned about the swings, but he said 30kW twice for two different time spans so that can't be it either.

I need your email address with your real name to prove that you are not a bot.

This is strictly needed for throttling reasons, your email address will only be temporarily stored in the volatile memory of the device.

(If you think there is anything wrong with this then you do get the point and silence speaks louder than words)

That type of design seems highly resistant to classic fmax raising techniques like pipelining because pipelining can't fix clock skew.

My suggestion is to just let the HTTP client itself be the MCP server.

Then you don't need an MCP server per service anymore, you just need one and a whitelist of authorized services.

Yes but even if you swipe the Rust magic wand and somehow reduce the vulnerabilities by 99%, you are still left with 20 critical vulnerabilities per year.

There is something about kernels that make them easy targets and it's not just the language.

I'm thinking a language change isn't enough... At least not for a kernel.

There has to be a pseudo userspace type of way to build a kernel driver. Basically, user space programs are fine, but kernel drivers need their own form of encapsulation without expensive context switches.

Something like memory encryption or memory access bounds. During the handoff you do not change the address space, you just restrict access to a subset of the kernel memory.

It's possible that we might need CHERI on stack pointers, specifically function arguments, because that makes it possible to grant a function access to a subset of the memory.

Yep, the reason why OpenBSD has had 5 times as many security vulnerability reports in 2026 than in 2025 has to do with the fact that OpenBSD is more secure and the reason is the code.

It was designed to have its vulnerabilities discovered in the year of agentic AI.

I wonder why 70% of the vulnerabilities in that list are attributable to OpenSSH, which is not exactly known to be a popular project.

We finally got the sufficiently smart C programmers and you still think that humans are part of that group?

Modern CPUs already split code and data between two types of L1 caches. So they are technically both "Von Neumann" and "Harvard" simultaneously.

It's also missing the point because modern buffer overflow exploits no longer write code into the stack, they overwrite the return address on the stack and assemble jumps to the end of functions known as "return oriented programming", but the underlying issue still applies to function pointers on the heap.

>1. That sounds like an Anthropic concern, not a concern for most customers who don't run their own model.

You're talking about this as if a bug or defect in their inference stack has no impact on you as the customer.

The standard library would just be C++ code that a compiler turns into machine code.

I remember a language where the core language types, including primitives and a bunch of keywords, were actually defined in the standard library and the compiler just special cased support for the types in the standard library for optimization purposes.

Your loaded question feels very silly from that perspective.

I'm pretty sure that it is too late for C++ to break the "stable ABI" they already have.

It's not too late to introduce an actual stable ABI though. However, it's not too late to do that in Rust either so I don't see the point in a language specific ABI in the future anyway.

multi-OS desktop application with

cross-platform container virtualization

integrated single-node kubernetes orchestration

plus various services such as

global container image hosting

automated supply chain security

distributed cloud build system

production container runtime

collaborative development sandboxes

vs

a curl competitor

Yes, they're in the same league.

He used the wrong word, he means a mock or testing harness or a digital twin of the factory.

"Even if you saturate a market, new people are born every day, at a greater rate than they die"

Not true.

Yes, but if you're willing to wait for the robots to become humanoid, the original task doesn't seem to be important or urgent enough to build said robot.

I don't understand why anyone is even talking about the cost the tokens when the anthropic is on both sides.

They pay for their own tokens and then they earn it back, net profit is negative, it's an expense but the expense is much smaller than the booked revenue.

They could be pricing each token at a billion dollars or a trillion tokens for a cent and the GAAP accounting wouldn't change.

If people have programmed programs to interpret neural networks, what is so special about the AI doing so? It's a forgone conclusion.

You can let the AI generate training code for the next architecture too.

It's not like the AI is randomly losing its ability to write software just because it involves AI.

Isn't it a bit hasty to say this, when one of the more powerful RISC-V CPU cores (Ascalon) hasn't been taped out yet?

I don't care about this "class war" or even ownership of the worthless "productive forces".

If you divide a product's cost into its "cost of availability" and the variable costs, none of this would even matter.

You could just ignore your noisy neighbors fighting over who gets to be the happy one, while you in your newfound freedom are simply happy.

If it wasn't clear, if you do not divide the two costs, then their fates are intertwined and so are the outcomes.

Wild cat AI lab reaches frontier lab parity with models from 4 months ago.

Surprisingly this is both mundane news for frontier AI lab customers and terrible news for frontier AI labs.

Well, since no one has sided with the author, let the math coin clipping keep going without pause.