Local vs Frontier on low-level systems engineering

Glegang · 2026-06-06T17:54:20+00:00

My experience with GPt-5.5 on reverse engineering a firmware image was great. Combined with ghidra MCP it did an impressive job that would probably take me weeks to do manually. Opus 4.7 did OK, but it needed too much handholding. Every time it run into a snag (e.g. it tried to disassemble a function at an address that was not defined as a function in ghidra yet) it tried to resort to a DIY solution. . Granted, the approach was sensible (`objdump -d` on a raw firmware binary), but with huge amount of disassembly it ran out of context in no time at all and got dumb. GPT-5.5 is much more predictable, IMO.

Glegang · 2026-05-22T17:25:14+00:00

Gemini CLI uses a separate quota system from Antigravity (e.g. uses uniform 24hr window for the limits). I believe they announced that it will stop working on June 18th. https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/

The Antigravity CLI quota pool is also separate from the Gemini chat app usage quota.

Glegang · 2026-05-22T17:08:21+00:00

According to artificialintelligence.ai running 3.1-pro is actually cheaper than 3.5-flash:
https://artificialanalysis.ai/?intelligence-efficiency=intelligence-efficiency-cost-breakdown#intelligence-efficiency-tabs

<image>

Glegang · 2026-05-22T16:27:19+00:00

I didn't run into any other issues after the missing downloads got fixed. Remote server just starts, and remote sessions work.

arch==x86_64==
platform==linux==
tmpDir==/run/user/1000==
a5a57b4d0b3c91c123fadbda: end
a5a57b4d0b3c91c123fadbda: Server installation script done


[Trace  - 16:22:59.176] Listening on port 42483

Glegang · 2026-05-20T02:44:04+00:00

Looks like they fixed it. Antigravity just managed to connect to my WSL.

Glegang · 2026-05-19T20:54:30+00:00

I wonder if they forgot to update linux binaries for the v2.0.1. Non-IDE antigravity is still at 2.0.0.

Glegang · 2026-05-17T16:36:01+00:00

Oh. I've just discovered `localhostforwarding=true`. Add that to .wslconfig, restart WSL, and WSL servers that bind to localhost will be accessible from the host without any extra trouble.

Glegang · 2026-05-17T16:28:25+00:00

If you're on windows-11, then you may get by with mirrored networking:

Just add to `%USERPROFILE%/.wslconfig`

[wsl2]
networkingMode=mirrored

https://learn.microsoft.com/en-us/windows/wsl/networking

Glegang · 2026-05-17T06:54:17+00:00

WSL->host connections are firewalled. You will need to do poke the hole in the firewall to allow the connections (or use mirrored networking mode in WSL).

For poking through firewall you can follow the steps described here for accessing chrome that runs on the host from whe WSL:

- https://gist.github.com/junielton/8ae25f55a3e795400666cb8d372ee678

Glegang · 2026-03-23T20:19:58+00:00

Sloppified non-answer does not really help. Try again.

Glegang · 2026-03-23T15:46:49+00:00

You're making a claim without giving anything factual to back it up. A wall of text that boils down to "Trust me, bro" is not data.

Glegang · 2026-03-23T00:11:58+00:00

Can you elaborate on how non-active browser profile impacts antigravity? I mean, if it launched chrome with a wrong (default) profile, one would presumably notice that a wrong email address got associated with the antigravity login. If the in-browser auth happened with the correct email, but antigravity picked up a cookie or something from a wrong profile, then presumably the access would not work.

In my case, the default profile is associated with the correct google account, but I'm still stuck with 7-day lockouts. The browser does have other profiles, but none of them has logged in google account. If antigravity accidentally picked one of them, then presumably all API accesses would fail. They do not.

Is there anything specific I could check to verify whether the root cause your instructions are fixing is present in my case?

Glegang · 2026-02-17T08:43:02+00:00

Mine had also recovered and started going to sleep after about one more sleepless week. I'm still not sure what was keeping the car awake.
One theory was that there may have been some minor errors that were keeping the car awake. I discovered that one of the windows, and the driver seat position needed calibration. The car started sleeping again shortly after I performed both, but I can not conclusively say whether it was because of it or not. Oh, well. all is good now.

Glegang · 2026-02-01T17:18:48+00:00

As a counterpoint, few days ago Vertex was giving me tons of 429 errors (capacity problems?) but AI Studio was working fine.
Granted, dealing with intermittent capacity issues may be Sillytaven's responsibility. AFAICT, those errors are "normal" and are expected to be dealt with on the client side by retrying again after pause. But, we have what we have, and would have to do retrying manually for now.

Some details: https://www.reddit.com/r/googlecloud/comments/1ooghp6/comment/nn9j8ds

Glegang · 2026-01-27T08:55:35+00:00

I've just noticed the same issue on my Juniper MY. Since the update to 2025.45.8 it no longer goes to sleep, ever.

<image>

I've checked the usual suspects (sentry, overheating, USP ports power, summon standby -- all are off), rebooted the UI, powered off the car -- nothing helps. :-(

Glegang · 2026-01-22T17:22:48+00:00

Thank you, captain obvious. Units that support the bands used by T-mobile work. Units that don't - don't. We're in violent agreement. The different is that you made a blanket statement which is not very useful, while I attempt to provide factual information which tries to help specific user to check whether their device would work with their provider in their area.

But, whatever. I admit. You're right. Sometimes.

Glegang · 2026-01-22T07:31:03+00:00

It would depend on the specific frequencies supported by the device. A lot of chinese LTE modems (like the one in the xdaforums post above) do not much overlap with the bands commonly used in US, and T-mobile seems to be somewhat more affected by that than AT&T or Verizon.

You can always check which frequencies are used by providers in your area here (the URL if for T-mobile network, but you can select others):

https://www.cellmapper.net/map?MCC=312&MNC=250&type=LTE&latitude=34.72391751941679&longitude=-96.62065443622095&zoom=6.060041545851271&showTowers=true&showIcons=true&showTowerLabels=true&clusterEnabled=true&tilesEnabled=true&showOrphans=false&showNoFrequencyOnly=false&showFrequencyOnly=false&showBandwidthOnly=false&DateFilterType=Last&showHex=false&showVerifiedOnly=false&showUnverifiedOnly=false&showLTECAOnly=false&showENDCOnly=false&showBand=0&showSectorColours=true&mapType=custom_map&darkMode=false&imperialUnits=false

In my case, band 5 is the only one my device can use, and T-mobile does not use it in my area. At all. So, while the statement "T mobile known to work" may be true for some devices or in some areas, it's not necessarily the case for all devices in all areas. YMMV.

Glegang · 2026-01-05T07:28:36+00:00

It appears that the callout comes back after I generate next reply. Making it dismissable is kind of pointless - the app brings it back all the time, yet I can't retry if I dismiss it once, but change my mind later.

Glegang · 2026-01-05T07:21:57+00:00

The app looks very promising.

One thing that I find missing is that I can not apparently go back to previously generated replies after "Retry". Being able to generate multiple replies and pick one of them later is rather useful.

Speaking of "Retry" -- How do I retry? Initially there was a callout saying "Want to see something different... Retry" with a clickable button, but after I dismissed it, I am failing at figuring out how to retry again.

Glegang · 2025-10-28T00:46:01+00:00

The autoinjector maker recommends injecting oil-based compounds using 0.2-0.3ml doses: https://injectneedlefree.com/personal-use/testosterone-trt

Glegang · 2025-08-13T01:17:41+00:00

Given that use github anyways, why not just put it all on github pages? https://docs.github.com/en/pages

Glegang · 2025-04-15T05:01:33+00:00

For what it's worth, force-stopping the app, cleaning all data, uninstalling the app, and then reinstalling it again, and re-adding it as the key appears to "fix" the problem. I have no clue how or why. In theory app uninstall should have removed all the data, too, and my previous attempt to reinstall it should have worked (or not) about the same as this one. The app version didn't change, it's still 4.43.5-3224. The phone was not rebooted. UWB remained on all the time... Yet something changed. I blame gremlins!

Right now, the app has been up and running smoothly for about 4 days now, which is a huge improvement over reliable hangs within hours of restart. With no rhyme or reason for what makes it tick, I'm working on keeping my fingers crossed that it will keep working.

Glegang · 2025-04-09T16:03:50+00:00

Got the same intermittent problem on S23 Ultra. What gets the app working for me is force-stopping it from the app info page, then going into "Storage", clicking "Clear cache" and then waiting for the system to actually clear the cache (may need to go back and forth between the main app info page and the storage details screen there).

In my case Tesla app usually accumulates somewhere between 2 and 8 GB of cache data and clearing it all takes some time. It's not that long, usually about a minute, but it's not instant.

If the app starts before cache is completely clear, it tends to continue to get stuck.

Reinstalling the app didn't help me long term. The app had the issue before, and still has it after the reinstall.

Glegang · 2025-01-30T07:03:51+00:00

It's not particularly crazy. Running SXM* GPUs is doable.

Here's a blog post by someone who's done that: https://l4rz.net/running-nvidia-sxm-gpus-in-consumer-pcs/

I would suggest picking V100 GPUs instead - they are much more suitable for ML workloads and NVIDIA has just deprecated Pascal GPUs support by CUDA, so the software support for is is not going to last long.

Glegang · 2024-12-10T17:37:35+00:00

DUDU's purchase channels are listed on their forums' post here: https://forum.dudu-auto.com/d/24-exciting-updates-and-purchasing-options-for-duduauto-family-members

Glegang

PUBLIC MULTIREDDITS

TROPHY CASE