babl-yc

I'm seeing this too.

API price for gemini-3.5-flash is 3x gemini-3-flash-preview so they might be throttling it 3x sooner. They should either drop API prices or not advertise AI Pro as supporting Antigravity.

https://ai.google.dev/gemini-api/docs/pricing#gemini-3.5-fla...

Interesting that the 3.5 Flash launches before 3.5 Pro. Historically it's been the reverse for Gemini since Flash is distilled from Pro?

Are they just training it a bit longer until it tops benchmarks?

This is cool. I'm observing a trend of "build a tiny version from the ground-up to understand it" a la Karpathy's micrograd/minGPT. Seems like one of the best ways to learn.

I switched to a new x86 machine. Running Linux on Mac just made things unnecessarily complicated and hurt performance. Im still open to using docker on Mac to run Linux containers but once you want a GUI life was simpler when I switched off.

I don't have an x86 laptop at the moment so sticking with Macbook for now. My assumption is Mac laptops still are far superior given M-series chips and OS that are tuned for battery efficiency. Would love to find out this is no longer the case.

I switched my desktop from macOS (10+ years) to Ubuntu 25 last year and I'm not going back. The latest release includes a Gnome update which fixed some remaining annoyances with high res monitors.

I'd say it pretty much "just works" except less popular apps are a bit more work to install. On occasion you have to compile apps from source, but it's usually relatively straightforward and on the upside you get the latest version :)

For anyone who is a developer professionally I'd say the pros outweigh the cons at this point for your work machine.

Arxiv should just retire "is all you need" in the title. Block the post and make them come up with something new. Anything.

Same for YOLO "versioned" models. People just claim they come up with "YOLO-v15" as if it was their trademark to version.

Luckily "web3" burned the idea of branding some technology as a version of the entire internet...

I don't know if you can generally say that "LLM training is faster on TPUs vs GPUs". There is variance among LLM architectures, TPU cluster sizes, GPU cluster sizes...

They are both designed to do massively parallel operations. TPUs are just a bit more specific to matrix multiply+adds while GPUs are more generic.

What Raspberry Pi is to Broadcom (developer-friendly SBCs), Beagleboard is to TI.

It's a slightly different approach -- Beagleboard is a non-profit and emphasizes openly purchasable components. But similar in that it is the cheapest way to tinker with SoCs from that vendor.

BeagleY-AI has 4 TOPS for ~$70. AI inference tooling is still improving but I've been working on it here: https://docs.beagleboard.org/boards/beagley/ai/demos/using-e...

I would expect nearly every active AI engineer who trained models in the pre-LLM era to be up to speed on the transformer-based papers and techniques. Most people don't study AI and then decide "I don't like learning" when the biggest AI breakthroughs and ridiculous pay packages all start happening.

I don't expect the majority of tech companies to want to run their own physical data centers. I do expect them to shift to more bare-metal offerings.

If I'm a mid to large size company built on DynamoDB, I'd be questioning if it's really worth the risk given this 12+ hour outage.

I'd rather build upon open source tooling on bare metal instances and control my own destiny, than hope that Amazon doesn't break things as they scale to serve a database to host the entire internet.

For big companies, it's probably a cost savings too.

I'm trying to make a DIY security camera that can run local models, and stream video over wifi.

The TI SDK makes it easy to run demos but making any custom apps quickly gets complicated unless you are familiar with embedded Linux dev, Yocto, etc. Certainly much more complex than iOS/Android.

Hopefully over time the tools for embedded can catch up to mobile.

Will be interested to see what their developer kit looks like when (and if) they release it.

I've been experimenting with the BeagleY-AI to build a little edge AI gizmo with a camera (Texas Insturments SoC + 4 TOPS NPU in RPi 5 form factor)

https://docs.beagleboard.org/boards/beagley/ai/demos/using-e...

There's a swarm on HN that upvotes anything uv related and downvotes anything questioning it's added value as compared to pip

There's still relevance in making it stupidly easy to make an LED blink and make basic apps on circuit boards. Education + weekend hardware hackers might look for something different in a framework than a professional.

But certainly for pro use cases the hardware specific frameworks are way more powerful (but also complex).

I wrote up a bit on Arduino vs ESP-IDF here https://bitclock.io/blog/esp-idf-vscode

To anyone at Arduino/Qualcomm reading --

If you're looking to make Uno Q SBC a gateway to more companies building on Qualcomm SoCs, please also release:

- Affordable HQ camera modules, with drivers, tuned ISP support for the board

- Low volume SoC purchases on Mouser/Digikey so we can move from evaluation board to prototypes

- Reference schematics

- High quality documentation and maintained Yocto layers for embedded linux development

- Ability to use SoC features like AI acceleration / ISP without huge headaches

You're right there is no way to specifically target the neural engine. You have to use it via CoreML which abstracts away the execution.

If you use Metal / GPU compute shaders it's going to run exclusively on GPU. Some inference libraries like TensorFlow/LiteRT with backend = .gpu use this.

I've always been a bit confused about when to run models on the GPU vs the neural engine. The best I can tell, GPU is simpler to use as a developer especially when shipping a cross platform app. But an optimized neural engine model can run lower power.

With the addition of NPUs to the GPU, this story gets even more confusing...

It sounds like you're working 8 hours/day and unwinding the rest of the time?

I never had energy for side projects with a full-time job. Just because some do doesn't mean it's for everyone.

Maybe there are higher value ways to relax than doom scrolling but I don't think being "unproductive" beyond 8 hrs/day is a bad thing.

Hopefully you can also find work that is stimulating and gives that sense of accomplishment.

One crazy stat --

In 2024, 21% of all bachelor's degrees awarded were Computer Science from University of Maryland College Park.

It was 3% in 2011.

I don't agree with the article that AI is wrecking job prospects. I see it is as companies are just now trending towards running leaner vs hiring every good engineer available during ZIRP.

Nonetheless, it's gotta be tough out there for new grads.

https://www.usmd.edu/IRIS/DataJournal/Degrees/?report=Degree...

One of the reasons I switched to Android was the freedom to make apks for my phone and not dealing with certificates, expiry dates, Google's approval, etc.

This is a depressing change if they follow through with this.

And "in the name of security" doesn't pass the smell test if there is no way to opt out.

I was in the market for a Linux desktop machine and considered the Framework Desktop. I respect their mission, but ended up purchasing a Geekom mini PC instead.

Given repair isn't practical with soldered DRAM and such, I prioritized small form factor, price, and quick delivery.

The Framework Desktop was a much larger form factor, 3x the price, and delivery wasn't for months.

That said, I still hope the company is successful so they have more competitive offerings in the future.

I'm going to attempt to get it running on the BeagleY-AI https://www.beagleboard.org/boards/beagley-ai

Similar form factor to raspberry pi but with 4 TOPS of performance and enough RAM.

I would say the target audience is anyone deploying ML models cross-platform, specifically ones that would require supporting code beyond the TFLite runtime to make it work.

LLMs and computer vision tasks are good examples of this.

For example, a hand-gesture recognizer might require: - Pre-processing of input image to certain color space + image size - Copy of image to GPU memory - Run of object detection TFLite model to detect hand - Resize of output image - Run of gesture recognition TFLite model to detect gesture - Post processing of gesture output to something useful

Shipping this to iOS+Android requires a lot of code beyond executing TFLite models.

The Google Mediapipe approach is to package this graph pipeline, and shared processing "nodes" into a single C++ library where you can pick and choose what you need and re-use operations across tasks. The library also compiles cross-platform and the supporting tasks can offer GPU acceleration options.

One internal debate Google likely had was whether it was best to extend TFLite runtime with these features, or to build a separate library (Mediapipe). TFLite already supports custom compile options with additional operations.

My guess is they thought it was best to keep TFLite focused on "tensor based computation" tasks and offload broader operations like LLM and image processing into a separate library.

This isn't really true. They are different offerings.

CoreML is specific to the Apple ecosystem and lets you convert a PyTorch model to a CoreML .mlmodel that will run with acceleration on iOS/Mac.

Google Mediapipe is a giant C++ library for running ML flows on any device (iOS/Android/Web). It includes Tensorflow Lite (now LiteRT) but is also a graph processor that helps with common ML preprocessing tasks like image resizing, annotating, etc.

Google killing products early is a good meme but Mediapipe is open source so you can at least credit them with that. https://github.com/google-ai-edge/mediapipe

I used a fork of Mediapipe for a contract iOS/Android computer vision product and it was very complex but worked well. A cross-platform solution would not have been possible with CoreML.

You could probably get away with f16 or even quantize to int8 and have a much smaller model, but your point stands. Users won't be thrilled to download a 500MB model for an app either.

So would you trade your founder equity for a fixed salary? My guess is probably not.

Equity is an extremely important factor for many candidates, especially more senior ones and executives.

I would not pitch it as future value, and instead pitch as % of company. If it's a minuscule amount that doesn't move the needle in offer conversations, than perhaps you are not offering enough, or you're identifying candidates who value more predictable income than investment in the company.

The first rule of working on Gmail is DO NOT change the interface.

The second rule is if you insist, please let us turn off your dumb AI feature.

Engineering titles have always had limited external meaning, but it's not an issue that needs to be "solved".

At a tech company I worked at, we started with no engineering titles (everyone was a SWE) but management eventually added them. My impression was this was due to (1) some candidate wanted a title in order to join the company and (2) executives wanted to quickly distinguish how respected + compensated someone was within the engineering org.

The reality is what one company/team values in terms of engineering skillset could completely differ from another. One company could be working the latest techniques in machine learning, while the other is working on web apps requiring database expertise.

Software engineering is far from a single linear skillset, so expecting titles to accurately reflect that doesn't make sense.

Glad to hear! I spent a bunch of time on that post so I was hoping someone would read it :) Good luck with your projects