speed_spread

Also, cheap maglev trains would be nice. Quiet, fast, reliable.

RISC-V is the ISA. They don't need to invent another one. They had Longsoon before. It's all just MIPS in disguise.

Half of the GPU game is software. I'm not saying that it doesn't or can't exist but I have yet to see what good Chinese software looks like.

For Silicon Valley, maybe. But this is Europe, where things are still rooted in reality.

The only thing it was designed for: recon. It's a spy plane. It has cameras and electronics up the wazoo. You fly it high and fast over a target, collect the info you need, refuel it and change target. Unlike a satellite, you can do that many times per day.

Against the USSR it had become risky because missiles could reach it? And satellites worked great during the cold war. But in a scenario where things got hotter and you wanted regular fresh intel from deep within enemy territory, the SR-71 could be irreplaceable.

Particularly toxic boron-enriched fuel at that, to sustain those same high temperatures.

https://en.wikipedia.org/wiki/JP-7

BMW i3 with REX came out in 2013

https://en.wikipedia.org/wiki/BMW_i3_(hatchback)

Different logs for different business opportunities.

And it's still just a machine operating under someone's order. What it does, what it says, where it goes: the owner of that prompt is responsible for all of it even if surprising / unexpected.

... And still come home late for supper

Probably not, but then again I have an ego, and I have other things going on in my life than decrypting random stuff for someone else's enjoyment. Both of which aren't true for an agent/LLM.

It's a machine - when we attribute it human concepts such as victory, mistakes, ethics, we also shift responsibility away from the operator and soon enough bad people will use it as an umbrella. The agent ate my homework! The agent bombed a school! Bad agent, no!

Cyclist still chooses the time, mountain and direction the bicycle gets pushed in. Bicycles have no agency and only go down because gravity. Bicycle will not "discover" tree or wall, any outcome solely the result of cyclist's decisions even if thrown bicycles don't have generally deterministic paths. Don't anthropomorphize the bicycle.

A cyclist pedaling up a mountain isn't a "collaboration" between a bicycle and a human. This is the same. You don't see feral bicycles roaming the land. All models are ultimately built and run by humans, with human-provided instructions. And as with any program, it's garbage in, garbage out.

If you want to stick with hardware, Behringer have a few cheap, fun and effective semimodulars (standalone, no need for rack) like the Neutron and K2. Best Bang for the buck.

Ah, asking the real questions. The speed of a closed ecosystem CPUs such as Apple's is irrelevant. As long as Linux or BSD doesnt't run on it in a stable fashion, I'm not interested.

It's not even that Linux is that great. But Windows and MacOS user experience have degraded so much in the last decade due to user hostile decisions and lack of vision, they essentially nullify advances made on the hardware side.

POWER should be the real competitor. If only it had laptop class implementations...

It's more efficient to use all the cores briefly and go back to whatever background task than have long running mixed load. This also matches performance expectations, you generally want the web page displayed _now_ and the compile to finish ASAP while accepting it will take _some_ time.

You forgot runtime agents!

IMO compile-time annotation processors such as Lombok and MapStruct are far from the most magic part of Java. They're straightforward code generators. Their impacts is localized to where they get applied and you can actually see the code that's generated. They're very good for diminishing boilerplate. They're no worse than Rust's very standard #[derive(xyz)] proc macros.

Having the code being generated on the fly (instead of a one-shot) means it follows the rest of the structure it's derived from i.e. equals() and hashCode() don't risk to be forgotten when adding a field to a class (hello maddening Map<> lookup errors)

Also, yes, Lombok is _funky_ in how it works but there are "pure" alternatives like AutoBuilder and AutoValue if one cares.

Because 'manuscript' means hand-written. LLMs think if they write it enough times, it'll become true. Then they'll grow hands and then not only will RAM be in short supply but keyboards too.

IIRC W2K didn't have one. Defragmentation can use different strategies which may impact the time it takes and additional perf gains if the right files are next to each other. The builtin defrag tool doesn't give any option. So "snake oil" I'm not so sure.

Also, a watching a proper defragmenter run was an OCD soothing experience before we had stray kitten and powerwashing videos galore. I know I'm not alone with this experience.

I get the sentiment. But for the record, O&O has been around for a long time, they were known for their excellent defragmentation tool, which isn't so much required nowadays. Their business model was never close to Adware (to my knowledge).

ShutUp has also been around for a while and always seemed to me like a O&O side project by someone who got really pissed at Windows taking the spyware tangent. The distribution model is still that of shareware / freeware (no source), because that's what O&O does. But as far as closed software goes, that's _probably_ as clean as it gets.

Just in saved maintenance they'd probably pay for themselves within a few years.

"october correctly" -> 3 Os

Nothing would have prevented building a nice, lightweight system in Java in 2007 had one thrown away the conventions that had infested it at that point.

Java's problem never was the language which has been as serviceable as any other since the JDK1.4 days. It is straightforward to compile (no metaprogramming, type erased generics), linking is delayed to runtime and dependencies are all precompiled to bytecode which _should_ make for very fast builds.

The problems came from the multitude of Internet-bubble era tool vendors which overcomplicated everything in order to sell high priced "corporate-level" solutions and imposed that certain coding style. Java is still known for this today because it appears in so many vintage codebases and is still being applied by coders who never revised their practices from 22 years ago.

My theory is that Rob Pike was jealous of Java because it has succeeded with a model similar to his own Inferno (bytecode, C syntax) and this aligned with Google's ask of developing something that would be outside of Sun's lawyers reach.

Chesterton's fence is strong with this one

You got what you paid for. They probably wished they could make cheaper cards too but it was never their primary focus and so eventually went back to making only expensive specialized cards where 3dfx, Nvidia, ATI and the like couldn't touch them.

Valmet in Finland does this too.

And GusGus

Yeah for a graphics company they sure do a lot of noise

Opportunity cost for Nvidia to prevent HF from going public or being sold to someone else. It's an insight into Nvidia's market prediction and what HF told them they'd do if left alone.

Got my hiking boots ready.

I don't doubt RISC-V can be used to make powerful cores but adoption as a general purpose CPU (rather than MCU) will need more than good numbers.

There's still a missing piece in the RISC-V ecosystem: a coordination body of platform-level standards. Debian took a stand with RVA23 support but then there's a ton of little things that are taken for granted on the PC platform such as UEFI and ACPI (as horrible as they may be).