dezgeg

> YouTube, Google, Google Maps, and Chrome

You listed products that have been around for ~20 years. Keeping up already entrenched products running doesn't correlate with being able to launch new products.

I'm gonna guess that the crew have been regularly landing while ignoring similar automated warnings in the past

Not to mention how any sort of TLS key exchange is supposed to happen with an unidirectional network.

If your session / computer crashes, for one.

Yes, most of this is all supported. There is a existing recipe for building an image that you just dd to and SD card and can boot in a Raspberry Pi (and other devices supported by mainline kernel + u-boot).

Kernel is a package just like another; so you just write your own recipe. Patching kernel recipe works just like patching any Nix recipe.

Not sure about the rockchip-proprietary boot parts; you may be on your own.

In theory device trees are supposed to be a OS-neutral stable ABI. Being able to put a device tree into unchangeable mask ROM is an often mentioned design goal.

However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.

So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.

It probably will help you maintain a better local fork, but getting all things upstreamed is the bottleneck and won't help too much here.

Correct, N64 and PS1 era projects can essentially always be strictly tackled one function at a time. There are very minor things (like string literal sharing) where some earlier function can affect later function, but the workarounds are comparatively simple.

On the other hand, I have heard even old MSVC is a nightmare. Various things are affected by hash table ordering (so the names of variables matter in some situations), stuff like order of #includes mattering, etc.

The term for that is byte-matching decompilation. This is not such project.

Don't most harnesses already do that for bash commands?

There is more normal looking code in other files. It sounds like the original game had animation data (or similar) embedded in the C code.

Games use plenty of native code; so much in fact that when Intel tried to enter the Android tablet market with x86 they had to write an ARM emulator.

4G/5G Telco equipment (ab)use HDMI connectors/cables in a similar way.

How is that any different from PyPI, npm, cargo, etc?

Correct way is to have everything as-if a source dependency, but a globally shared cache system that can automatically provide artifacts if that exact version of source has already been compiled.

Any system that can only consume manually built (and even in worst case, only tagged and globally pushed) dependencies is horrible for cross-module development, like large scale refactorings and the like.

Yeah, for all the hate Gemini gets, at least it isn't obsessed with adding comments and it's output is more readable than recent Claude's.

I extremely doubt it's Gemini - all previous Geminis have had very different output style from other models. In a coding harness Gemini is extremely quiet and mostly just does thinking and tool calls, with the thinking blocks heavily summarized.

Also Claude and the Chinese models really like to say "Let me X", Geminis preference is "I will X".

I wonder if pilots' medical checks would catch some of these early?

GPT-o3 was the first OpenAI one to beat Red. The harness used by GPT Plays Pokemon is the most featureful one of the main competitors (GPT, Claude, Gemini), IIRC.

Community maintained spreadsheet of the runs: https://docs.google.com/spreadsheets/d/e/2PACX-1vQDvsy5Dt_-P...

How so? In my experience, the peak of Device Tree days was with the final 32-bit ARM chips before move to aarch64. Back then you had U-Boot which did minimal stuff and after that the kernel had full ownership of the hardware, no management firmware layers or extra code at runtime.

It's during the move to 64-bit aarch64 where things started to imitate the x86, with more and more always-on firmware and secure monitors and whatever being introduced. Nothing really to do with device tree, in fact ACPI is being pushed to the ARM too, yet again hiding more details of the hardware towards proprietary bytecode.

Essentially a vibe-coded clone of https://android.googlesource.com/tools/repo ?

Seems like I have much better results with Gemini <= 3.5 Flash being able to solve 10 Lake levels. Of course there may be methodology differences (like how many times the level is attempted from scratch).

I wonder if the reasoning tokens are still being accidentally discarded between turns in those tests. It seems to be much more important to preserve those for Gemini, as it likes to stay quiet and and just make tool calls, unlike Claude that yaps a lot what it's planning to do.

Good stuff, I've been trying this myself with Geminis: https://www.youtube.com/watch?v=brkP58pZ23w&list=PL8C_UWcLmv...

Will be interesting to compare the results.

I've been trying this too: https://www.youtube.com/watch?v=brkP58pZ23w&list=PL8C_UWcLmv...

Cool to see others trying Baba Is You too.

No, tool definitions are provided via some other mechanism.

I don't think this is about core kernel semaphores but rather the SysV semaphore system calls?

Ah, but you see Xbox security updates won't be for your security. They will be for protecting the console's security against jailbreaks etc.

> Today I am filing: > 1. A payment dispute with the email payment processor for the 7/29 transaction of $451.15 > 2. A complaint with the FTC and California Attorney General (retention of payment without delivery) > 3. A small claims filing in San Francisco County for $451.15 plus costs

I wonder did their prompts include a fake location or have the models assumed that Silicon Valley is the center of the universe :)

System prompt for something like Claude Code should be identical, no?

The bottleneck was with the serial protocol between the drive and C64. It was done via bit banging in software due to some chip bug. The fastloaders replaced the protocol with something more amenable to bitbanging.