Oh god. If I spent enough time digging through my ancient Slashdot posts, somewhere back there there are posts of me going, "While I loved the strategy behind Falcon 9, I'm really not keen on this plan to make Starship out of huge carbon fibre tanks, that sounds like a really failure-prone solution..." I'm glad they only spent like a year on that idea before deciding it was dumb; somewhere back there there's also a bunch of posts of me cheering their switch to steel ;) . SpaceX still keep having random COPV problems (most of which they don't even make themselves). Not too encouraging for the notion of the cold gas thruster add-on to the Roadster, where the plan is to replace the back seat with COPVs, so you have a COPV right behind your head.

Electron has been getting by on CF, and honestly I'm impressed, but they've also been only working with very small launch vehicles thusfar. We'll see how neutron goes...

Don't get me wrong, there's a lot to say about printing small rocket parts, such as for the engines. But they were printing basically sheet metal cylinders, which is such an immensely slow and inefficient way to go about it, and it left them with parts that were heavier and less aerodynamic (rougher surface). Crazy that idea ever got any funding.

The one seen over Moscow might have been, with a bit more thrust...

"SapceX has got to be a huge scam too" - SpaceX launches the vast majority of the world's commercial cargo to orbit. The Falcon 9 FT has the highest success rate of any rocket with a statistically significant number of launches under its belt, and is dirt cheap. SpaceX's core operations are roughly breakeven, but that's including subsidizing the development of Starship. Starlink is a money printer.

There are lots of things sketchy about the SpaceX IPO, to say the least, but SpaceX, as a company, has been extremely successful with rocketry.

MidJourney was the first sizable AI company to become profitable, having done so back in 2022.

The funny thing was that I knew him for like six months online before I realized he was fully paralyzed. He's been covered in the Finnish press a number of times. Amazing guy. Up until recently he was living in a house he built himself before ALS struck, but the medical service decided he was too far away and he had to move closer. You lose a lot of control over your life with ALS.

He wrote a book about nuclear safety engineering recently, which is a fascinating read, and which I strongly recommend.

The restrictions are a mix of reasonable nuisance management and paranoia about who is flying drones, what they can do, and chain of custody.

Beijing proper is a city with a population density of over 21,000 / km^2 -- so you can imagine the chaos if any tech enthusiast resident could fly a drone without a permit. Except for a couple of free zones in the outer boroughs, New York City restricts drone launcing and landings within the city to flights with a permit and flight plan, because otherwise the sky would be black with drones. Many cities -- both red and blue -- have zone restrictions for drone flights, and those currently hosting World Cup matches have tightened them for the duration of the tournament.

BTW, AI is a godsend for ALS patients. Even with an eye tracker, your writing throughput is low / tiring compared to typing, and of course you can't do anything that requires physical activity (painting, playing an instrument, speaking, etc). AI tools help fill the gaps.

Did *she* want to die? Did *she* want to be "released"?

Did she have an eye tracker, to allow her to communicate naturally?

Motor neurons dying != brain control of motor neurons dies.

Anyway, you don't need a brain-computer interface for an ALS patient to work. I have a friend in Finland with ALS who works as a consultant on safety for a nuclear reactor startup (he was a nuclear safety engineer before becoming paralyzed). All it takes is an eye tracker.

The biggest problem is the typically short and unpredictable lives of ALS patients. He has lived abnormally long (I think something like 13 years now), but a large part of that is due to him thinking like a nuclear safety engineer (backup on backup on backup, training his nurses to have zero tolerance for error, etc), and still has a close call like once per year or so, and I regularly worry when I don't see him online in a while that something happened that killed him. A tube comes off a life support system. A nurse forgetting to reconnect something. A mucus plug in his airways. Etc. ALS patients' lives are fragile. He does CAD design for parts on his computer (it's too hard to do it with the mouse using the eye tracker, so he designs the shapes programmatically) and orders them 3d printed to correct any deficiencies he finds in his support systems.

ALS patients also have to constantly fight the medical system. Even in a place like Finland that will actually do long-term care for ALS patients (which is very expensive), it shows that it would be much more convenient for them if those danged ALS patients would choose to die (and there's often pressure put on them to do so). One of my friend's goals is to outlive a doctor who told him he would only live a year or two put a lot of effort into getting him to choose death. It was a battle to get long-term ventilator care. It was an even bigger battle to get to use a cough machine and to be able to control the settings on it; without regular, meaningful cough support, your lungs fill with mucus, and you'll probably eventually die of a mucus plug, pneumonia, or whatnot.

By contrast, ALS patients today can actually live a decent life using eye trackers. It's not like before when you had to tediously spell out things one character at a time to a helper holding an E-tran frame. Given that 1 in 500 people will get ALS at some point in their life, we really should be allocating a lot more money toward researching cures, even if purely from a cost-saving perspective.

(One final note: if anyone here starts getting peripheral weakness and worries its ALS: your instinct will be to exercise more. Do just the opposite. If your peripheral neurons are dying, the last thing they need is more work. ALS overwhelmingly strikes active people - one researcher I was reading noted that in her entire career, she's never met a couch potato who got ALS. Take it easy, see a doctor immediately, and if it is ALS, start preparing early, but know that you do not have to be forced to choose to die, so long as you can get care. You can live a decent, productive life if you choose to).

Ok so I understand that they bought up Morpheus a while back, and it does some fantastic things with current state of virtualization with all the terraform and container tools that one could want...

But where did the underlying bare metal hypervisor come from? Is it BSD based so that it can be commercialized fully? Is it a significant enhancement over ZenServer? One doesn't usually just poof a new bare metal hypervisor out of nowhere.

Whether Anthropic was trying to hype about Mythos / Fable or not (and FYI, it is a pretty big leap forward), they absolutely did not want to get public access shut down. The US government very much seems to want to have exclusive access to it for now.

Also, to clarify the "jailbreak": They took open source projects that had known vulnerabilities, as well as deliberately introducing vulnerabilities into some other projects, then asked Fable to fix them, and then asked for test scripts to demonstrate that the exploits could no longer be exploited - the implication being that they could then use those exploits against unpatched systems. But what's the logic here? The challenge isn't "how to write exploits against known bugs", any model can do that. The challenge is finding the bugs - something Mythos / Fable has proven better than previous models at. Even if Fable refused to write said test scripts, it would automatically downgrade to Opus 4.8, and then *Opus* would have written those test scripts. Or any other model out there could do it, including free open source ones that can be safety-abliterated at will.

"I want to use claude code to run 10 unattended Chrome beta testers [more info about what is being tested and specifics]. Write me one or more md files to execute and give me instructions for enabling Chrome mcp, then give me an sh script to launch 10 separate Chrome instances on macos."

I wrote that exact prompt, more or less, a month or two ago, and then other iterations since then, and it's been working very well.

Using LLMs to create prompts for LLMs to use was a good realization.

This makes me laugh! I see classes at universities and colleges on using AI. Not just in the tech arena either, I'm talking liberal arts--med school, law school, you name.

As best as I can tell, "how to use AI" is more or less "don't be a dumbass."

To be succesful with AI, you need the same skills you need to be successful otherwise. Analyze problems, test solutions, think critically, etc. Unattended vibe coding or turning in of AI slop is the same as people who cribbed essays, copied and pasted from Wikipedia, etc.

IMHO, you still need to be a developer to be able to use AI effectively. If you start with a really solid schema, or an existing framework, AI is great at building on top of that. If you give it specific guidance for what and how you want it to develop code, it can do a good job. It is NOT just "lol write me a network utility lol" -- that is a path to disaster.

I've also had good luck with updating and modernizing older code, migrating to a new frameework, and refactoring.

If i'm using claude code, my steps go something like this.

1. Using plan mode, analyze the code base, create a thorough plan and testing strategy for XYZ (Or I provide SQL schema, or I provide a thorough plan of what I want to do, etc.)
2. Refine Claude plan mlutiple times until I'm happy with it
3. Start with writing a set of unit tests to confirm current behavior
4. Implement the first part of the project (this is not coding the whole thing in one shot)
5. Run unit tests, check for regressions.\
6. Rinse and repeat..

Steps 1 and 2 -- with no code being written -- are probably the most important parts.

I should also add that, imo, this will be a relatively short moment in time. I've seen people who are spinning up dozens of agents at the same time -- backend designer, frontend designer, security consultant, css specialist, etc -- that all work together and iterate amongst themselves.

We've been running a beta test of some new software, and one beta tester out of ~30 people hit an error. We could not reproduce it. Claude took ~5 hours, but using Claude to remote control Chrome, in conjunction with analyzing the state of the backend database, and auditing the codebase, Claude was able to reproduce the error and suggest a fix. In this case, we disagreed with the fix (rather, we went for a bigger logical change as opposed to a bandaid), but we've had really great luck with using Claude Chrome mcp as a beta tester.