Problem is they happily do that, with noisy and polluting portable gas generators in big trailers.

Note when Elon declared that the only practical path forward was tens of thousands of starship launches a year to let the datacenter be built (which is stupid), his assertion was that the solar panels and launch logistics were easier than making more turbines for natural gas generators. Again, a stupid stance, but it says that they consider plopping down natural gas generators a critical path..

one cannot expect our incompetent upper class overlords to produce anything but even more overpriced and unimaginative technology, let's not forget the goal is not to produce good tech but to extract the most revenue in order to increase shareholder value

our devices and our services are designed to exploit us, manipulate us and surveil us, welcome to our classist corporatocracy

To make that analogy, you have someone who notices their toaster is running some novel SoC with a new instruction set 'z36' that has not run Doom. So they go to the manufacturers site, get the SDK, compile Doom with it, reflash their toaster, and show Doom running on it. Sure, a decent fun story of it's own right.

Then they post that they 'Wrote a 3D game from scratch to run on a toaster"

Followed up a few days later by the guy's boss pointing to that blog post and declaring that Unity and Unreal and PCs are all dead because this guy compiled Doom for z36

Sure, they carefully spend weeks crafting the test cases with test data and then spend tens of thousands and probably have to buy it a license of Word to use as a reference to compare test execution on the LLM output versus reference implementation...

Or they could just stop at having bought Word....

The problem here is that this example leaned *heavily* on the software desired already existing and the LLM having access to run the original software as it endeavored to make a knock-off. And then per analysis and issues it kind of did a crappy incomplete job...

The question is what happens if an LLM creates a knock-off and a human goes to redistribute and maintain the work as a viable alternative... Does the original software vendor go nuclear because the LLM can't be considered to really do a 'clean room' reverse engineering?

Who is 'we'? I don't think the LLM is up to the task of making a C compiler that can target an architecture with at most 256k of RAM and without a reference C compiler to work with, like it did for this. The LLM basically got told to write a knock off of gcc, and based on some of what happened, it absolutely needed a working gcc to work from to create the sort-of knock off.

I mean, what next iteration?

I would also say that this seems the opposite of useful for no longer working hardware. If the hardware existed, then we still have a C compiler for it. If you say you want to modernize that compiler, but the hardware is a dead platform, why are you trying to modernize for it anyway?

Let me extrapolate to the point that maybe you are talking about a compiler for some future architecture. Problem is this example needed:

- A human to carefully craft test cases and rescue the LLM when it spun out
- Ability to compare with an existing, working compiler behavior... Meaning you would have to write a compiler before you could have it write a compiler...
- Ability to re-execute over and over again after shuffling the code, meaning you need working hardware to actually run the tests over and over again, and you need to know the *hardware* is good because when a problem happens, the LLM can't determine if the hardware is flawed or if the compiler is flawed, it's just too ambiguous when you have no basis of confidence on either one.

These models aren't parallel in their nature, so spinning up multiple 'agents' is just how you manage concurrency. Just like forking a process. I think it's a bit werd to call each instance a distinct 'agent', it is trying too hard to humanize this very synthetic thing...

One thing that LLMs are pretty good at is translation, and training on a large corpus of Rust and C code as well as numerous C compilers means that this task is utterly useless given the context of the existing compilers, and trying to prove it can make projects "from scratch" is disingenuous when you are just having it implement very well trodden territory.

Hell, someone posted an experiment in writing a C compiler in rust to github at least once before, so it even had a C compiler written in rust that was probably already in its training material.

This was another promotional stunt that is dangerous as some business leaders fail to understand that it's trying to piece together a clone of existing technology and assuming that is fundamentally as difficult as a human team would find the same task. But the task is a 'stupid LLM trick' that does something that *would* be hard if it hadn't been done before, but no one would do it now because what a waste of time it would be to bother.

I'm willing to commit to provide a C compiler in a single day for a tenth of the cost:

# dnf install gcc

For a bonus, I'll even do two:
# dnf install clang

Don't know what I'll do with the other 7.99 hours of the day though...

This reminds me of how Khaby Lame mocked all those overcomplicated "life hacks" by doing the obvious simple things.

They don't want too much experience as they also have the experience to recognize the leverage they hold, demand appropriate compensation, and not put up with abuse that more inexperienced people will take.

I have seen time and time again companies faced with two possible paths forward, one that will work and will work better, and even frequently cheaper, *but* some key people will become "indispensable", and that risk is so high they will do all kinds of things to avoid it. Basically, if you become too good at your job, you better be "in" on the politics and probably be in management so that your importance is on comfortable terms with the executives instead of technical skills.

Whoops, the site I was using neglected to update the percentage when I changed the interval... So it said '6 months, down 0.29%' for silver but it meant for the day despite selecting for the 6 months... Guess I should verify a UI actually works like I would have expected rather than assuming asking for 6 months updates all the elements on the page...

You do get that if that were the story, BTC would be *up* versus the USD right? The fact it is down against the USD by 42% means whatever weakening the dollar experienced, BTC experienced 42% *more* devaluation...

Silver is down pretty significantly, Gold is essentially flat, the stock market is a touch down over the same time period... Of course the USD in general is down a tad compared to Euro for the time period.

I'd say it's annoying as all get out, especially when it obnoxiously suggests something it wants to change that is wrong and refuses to recognize something you *thought* it would slam dunk based on everything to that point..

But in some select circumstances, it can accelerate the dumbest tedious work.

For example, a third party has forced us to significantly rework our codebase to use their 'new' library. The new library is crap, it makes you have to manually manage a whole lot of stuff that was abstracted away in the previous library. In any event, it demands a very tedious reworking of code. To the LLM credit, after I changed a few things by hand I could frequently tab over to the next spot and it does a decent job of spotting similar things and it saves me typing. It's not like a simple rename, the logic has to be reworked, so the old standby of search/replace is non-trivial, so it gets within the reach of LLM. It's still a little puzzling why sometimes it misses stuff, and sometimes it wants to 'correct' something that currently works in a way that would break it. But today it evidently generated half of the changes on that migration project and saved me a bit of hunting and typing. Has to be watched like a hawk, but saving me key presses is... I suppose, worth it. Evidently my statistics say that I average letting it generate about 7% of my contributions, but days like today do let it shine a bit by cutting my annoying chore work in half.

Other fun thing is when I ask it to do a code review, it commonly ends up doing "You seem to be doing X. It would be better to do Y" I say "why not" and accept the change and ask for a review and then it says "It is a bad idea to do Y, you should do X instead".

True, the linear versus track density isn't known, and I've been a bit optimistic on that....

Of course, now they have dual-actuator drives, though currently it's just splitting the lower and upper platters to be served by independent actuators, one could imagine quad-actuator with two more tracking the same platters to double the potential throughput. As well as investing in making the heads capable of concurrent operation.

While my example numbers may be optimistic by pretending the interface technology would be the bottleneck, the general idea is that there are ways we could make a platter based drive have streaming performance that could actually have it reasonable to scrub as this thread talks about or slurp off the data in one go to somewhere else. So if a 140TB makes sense, we might be able to beef up the logistics around it.

I suppose alternative more pessimistic math and assuming you at *least* went to 24Gbps SAS and felt comfortable about saturating it on sequential read, you'd at least be in the ballpark of a 32 TB drive on SATA 6gbps, which the market seems to have accepted the slow full drive access that would mean.