Here's actually a cool example, the Agentic LLM can parse the picture and search the internet about it.

And here's yet another Agentic AI feature, the long-term memory bros.

The model can decided to save small pieces of information for the later usage.

Here's a new downloads page concept made by same guy who makes our artworks and posters recently, anything you'd comment about it?

And here's my quick mockup, this one is rather based on a different approch to select devices, you don't have to search for them or click a button to see the list of devices, you can already see all the devices right away. As a disadvantage - no NEWS.

Look, apart from being useless, here's another reason to not include RGB to your next PC build

https://www.youtube.com/watch?v=H_O5JtBqODA

I didn't use this nothing so much but the first impression is pretty much a very good one, it looks wonderful, it feels very nice as well and the screen size is just right for my paw to hold it.
It's just that the phone is a little bit too thick.

Anyway, if what, the next main phone of mine could be easily nothing.

Some of the Nothing Phone lore:

Not gonna lie, logcat of the stock ROM (not rooted not modded) is hilarious

// The Jenkins at home

Here's a cool animation effect I added

I would also like to share the details of the new OrangeFox CI integration in the FoxBox.

The "normal" way to build AOSP (recoveries are derivatives of AOSP) is that you have a very huge AOSP sources directory (300–400 GB). You also have your device, vendor, and kernel trees, and that's how you build it.

However, there are three main problems:

- Trees – All of them have to be very strictly maintained. Each tree should not export modules (kernels love to export modules) that are already being exported. That means you have to split such trees into common trees, and nobody likes to do that.

- Even if you do it and split the trees, updating things becomes very tedious, as each change in a common tree would affect every single tree that uses it.

- It's rather insecure because the tree of a completely unrelated device can actually copy/build/link anything to all other devices.

- Managing trees is already a hassle. Big projects use something called roomservice, which pulls trees from their Gerrit/git, checks for dependencies, and recursively pulls them as well. It does require manual intervention for even the smallest things, for example, when you want to change the branch, or when one of the thousands of repos moves or becomes unavailable.

My implementation utilizes immutable builds, which means that every single build is not influenced by any other, nor other trees and configurations.

How does it work?

I've made a service called FoxWorker, which pulls from FoxAPI for new tasks, creates podman containers that have read-only access to the OrangeFox sources, and copies the sources to a temporary location. It then pulls the device tree and checks for a file called fox_factory.json, which has the following structure (see the picture). This serves as a kind of build recipe for FoxWorker to execute, it pulls the repositories accordingly and initializes the build.

Specifically, I want to talk about two things:

1. Copying the whole sources (again, it's ~350 GB of very small files):
Now, this would be complete nonsense with a traditional file system. But since I've been using Btrfs for over 5 years, which has a copy-on-write (CoW) feature, that allows the file system to copy only the metadata instead of the actual data. On my machine, copying the entire sources directory takes about 20 seconds.

2. Podman containers:
That's yet another technology I've used for over 5 years, and it's how I host every single service of mine. It works even better for build jobs. By default, Podman uses rootless daemons which, as is obvious from the name, run the daemon without root privileges, resulting in increased security. Podman also integrates pretty well with SELinux-enabled hosts, which I always use as well.