thirstyskyline

On a site seemingly abandoned by Nvidia for events, called events.nsv.nvidia.com, a spam marketing operation moved in and posted more than 62,000 AI-generated articles, many of them full of incorrect or incomplete information on popularly-searched topics, like salon or restaurant recommendations and video game roundups.

On the vaccines.gov domain, topics for spam blogs include “Gay Impregnation,” “Gay Firry[sic] Porn,” and “Planes in Top Gun.”

More recent updates: https://www.androidauthority.com/google-not-killing-aosp-3566882/

https://grapheneos.social/@GrapheneOS/114665423084970607

And updates from the Graphene chatroom:

it [porting] is not faster than expected. we finished most of what we thought we were going to need to do already. if they had not dropped a bunch of what we need, we could be doing experimental releases soon. instead, we do not know how long it's going to take to add back Pixel support to Android 16. Android Open Source Project no longer supports Pixels. we have to implement it ourselves in a new way, different than what we have done previously. we are missing our most talented and productive developer due to the conscription situation. the kernel port is a trivial part of it and they made that harder by no longer publishing kernel commit history and splitting the previously unified kernels into 3 separate groups.

Pixel 6, Pixel 6 Pro, Pixel 6a and Pixel 9a share a kernel branch. Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro and Pixel 8a share a kernel branch. Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL and Pixel 9 Pro Fold share a kernel branch

there is a 1 line difference between the first 2 groups. there are major differences between the first 2 and the 3rd group.

before Android 16 it was fully unified, they messed that up, and dropped source code history from AOSP for Pixel kernel modules. the Pixel device repositories and hardware repositories are gone so we'll need to fork the 15 QPR2 device support and remove all the code, getting it from adevtool for now instead. this kills our hardware-based USB-C port control feature. we'll need to reimplement it in a new way