From reading online, linux battery seems to be a-lot better on the new intel board, and also if you configure linux with sleep to hibernate, you get really good behavioral performance. My experience is that the sleep states really drain the battery since the low power mode is not _that_ low power, at least with the ram I have.

For context I have a 13th gen intel with the old battery and only get ~4hrs of battery life, but generally go a week or 2 between full shutdowns, since I hibernate all the time. I can close the lid, throw it in my backpack, not use it for the weekend, and when I open it it is ready to go, not having lost charge.

I generally have a better experience than when I was on windows.

I had good experience within warranty period, but there was still some funky-ness with a non-posting board... I do sometimes wonder if it was a bios corruption - It died after running the battery 100% to zero...

That being said, I think the particular bios-chip is a design flaw that they should communicate about and fix for future boards... Probably a teething issue thing, but they should fix it. Either a usable replaceable chip so they can just send out a fix, or the fallback bios chip....

So one of my thoughts is maybe AI makes this more viable. You continually refactor the code base. Often when you start something you do not know the correct abstractions anyway - so vibe-code it.

Then once you have the kinda-sorta prototype, do a full rewrite, try to do component modules with interfaces.

(maybe do multiple rewrites depending on architecture complexity)

Then incrementally improve the software quality of each of the components.

---

My thesis in this is that the cost of a refactor has dropped precipitously, LLMs are really good at doing translations, and are pretty good at finding good abstractions if you work them a bit. It is also much faster, becuase in your refactor you try and focus on the big picture and interfaces, and yolo the components... Make sure that they work, but if there is a particular edge case you can fix it later.

I don't know for sure, but I am testing this out and am halfway through a rewrite of a large project into rust from c++ (second step from above) - I am mostly vibe-ing the components, But am paying a lot of attention to the interfaces and layout.

This is what I've observed too in actual real life.

Massive refactoring operations that would've never been scheduled, because they would've needed a senior programmer allocated to it for at least a week can now be done to ~80% completion with a good prompt and an LLM in an afternoon.

then the senior dev only has to spend maybe a day or two in the final 20%, mostly confirming that nothing was missed.

This is really cool - I really like the beam search idea,

this is the first time ive heard of beam search. i would have reached for a genetic algorithm of some sort, although it seems like some stochastic versions of beam search exist to avoid local minima. i wonder if there are any good frameworks for building these that agents can construct and use.

I think the question is how do you keep track of the ideas that the agent is pursuing - like I was working on this for implementing a fft, and doing the optimizations, but I held its hand and was like - hey let's go back and retry this older thing you discounted because of a 3 % slowdown.

beam search works when you have enumerable branches or some predefined dimension

You dont have to repay per hour? It seems like that is a design issue - Like yes we will keep these in whatever cache you want, but you will have some sort of renewal period

You should have a hosted site for this - It is entirely frontend - right?

almost! the editor/compositor is fully browser side, but the server is doing real work: project.json lives on disk (thats the whole point, any agent or script can edit it and fs.watch + sse hot reloads the ui), plus ffmpeg for the final export encode. so it needs the local server for the actual workflow.

a hosted demo mode is a good idea though, project in localstorage + sample footage + mediarecorder export would let people feel the editor without cloning. the one thing it cant show is the main trick, watching an external agent rebuild your timeline live, since theres no local file for it to edit. might do a stripped demo build if theres interest

Not knowledgable, but irradiated flies should not be expected to be irradiated again. There are 3 population pools:

1. The Factory spawning population - This is self-sustained, and never encounters radiation.

2. A subset of the spawned males from the factory population are irradiated, making them sterile.

3. The wild population, consisting of the sterile males + wild males + wild females.

If for some reason the sterile population is not fully sterile (unlikely), then maybe there is a gene that helps for radiation resistance, but the children of that strain will not encounter radiation, so it fades away.

The factories are not going out to the regions where the flies are deployed to get new fly studs.

There can be selection pressure for females to mate with multiple males.

Releasing sterile males only works for species that mate only once or at most twice, and rapidly falls off in effectiveness for species where the females mate many times.

Your 1. By itself would mitigate the risk I think.

but some tokens are not really needed? This is probably bad because it is mismatched with training set, but if you trained a model on a dataset removing all prepositions (or whatever caveman speak is), would you have a performance degradation compared to the same model trained on the same dataset without the caveman translation?

> How do they audit that Anthropic can't alter model outputs for contexts they (the ethics board or whatever it's called, can't remember) don't like?

I was thinking that Anthropic would just be providing the models/setup support to run their models in aws gov cloud. They do not have any real insight into what is being asked. Maybe a few engineers have the specific clearances to access and debug the running systems, but that would one or two people who are embedded to debug inference issues - not something that would be analyzed by others in the company.

The whole 'do not use our models for mass surveillance' is at the end of the day an honor system. Companies have no real way of enforcing that clause, or determining that it has been violated. That being said, at least historically, one has been able to trust the government to abide by commercial agreements. The people who work in cleared positions are generally selected for honesty, and ability, willingness to follow rules.

I think what you are describing is technically possible (not my immediate domain, however). They don't have real-time insight into what the model is being used for, you are correct about this afaik. But the incident that kicked off this paranoia was Anthopic calling around after the fact to try to find out how JSOC was using the model during the Maduro raid. None of the context of those questions are public, and I doubt they will become public, but it stands to reason that the nature of the questions was concerning enough for the War Department to cause them insist on the "any lawful use" language to be inserted into the contract.

>The whole 'do not use our models for mass surveillance' is at the end of the day an honor system. Companies have no real way of enforcing that clause, or determining that it has been violated.

You are also correct here imo, with one important caveat. Even if private companies have the means for enforcing that clause, it is not their business to do so. Maybe that's the crux of the problem, one of perspective. The for-profit entity in these arrangements is not and can never be trusted as the mechanism of enforcement for whatever we, as a republic, decide are the rules. That is the realm of elected government. Anthropic employees are certainly making their voice heard on how they believe these tools should be used, but, again, this is an is versus ought problem for them.