Do you know if that's the process for the 2026 Signature? I don't remember exactly but GrapheneOS may have mentioned that for the current Motorola flagship devices the unlocking isn't as onerous.
Considering Motorola is doing a lot of the porting, I would guess it will be improved or will be easy.
If there's a "process" that isn't just something done on-device, it is vulnerable to a rug pull (see LG, Sony, Nokia) where they just suddently stop offering it or the service just stops working somehow.
> I think we just have different ideas of what the word "reasonable" means.
I think we just have different ideas of what the term "building blocks" means.
You cannot add (or remove) part of systemD as you wish: on a Linux system I cannot replace journald with something, and I cannot bring journald over to FreeBSD. SystemD is tightly-coupled (heck, they even borg'd in udevd, which was an independent project at one point).
Building blocks in my mind are like Legos: you can put together the thing you see on the box, but the individual (literal) blocks can be used however you wish.
There is difference between mandatory one implementation and set of funcionalities. Systemd is monolit with visible parts that provide somewhat modern
funcionalities in 'nix world.
And there is no serious developers in 'distro' space, except RedHat. And, really, there is no such thing RedHat we have in old Linux days - it was devoured and we just have a label doing corporate propaganda.
So when few modern init systems were hatching RH dropped systemd and, as RH is main force in distros development, it gained dominance.
And since then thing are getting worse.
Eg. cgroups ? systemd first used them and so much hype happened. But is it deserved hype ? No! They implemented cgroups v1 when cgroups v2 was available. And cgroups v2 usage was blocked for years. In systemd too.
Do not make mistake of not seeing difference between good and modern functionalities and one codebase with funding that block real development.
You might have done barely working duck-taped Bash scripts; not eveyone who calls themself a 'system admin' is competent. But actual professionals who ran these systems since the 1970s had carefully written, fully functional scripts and we were quite capable of keeping hundreds and thousands of servers running just fine. Being bad at your job isn't the tools fault.
All Bash scripts are duck-taped by definition. It's a shitty duck-tape language.
> thousands of servers running just fine
Err yeah well you might have noticed these things called "laptops" and "desktops". SysVinit was... fine.. on servers. It worked badly on desktops and not really at all on laptops. I'm pretty sure the post introducing SystemD explained it all in detail if you want to learn something.
Bash doesn’t just stop working because the x86 CPU is inside a different form factor. And actually Linux (and BSD too) did used to run on commodity desktop for local ISPs, newsgroups and so on and so forth. That was part of the reason for their success story: Linux and FreeBSD meant smaller Internet-facing business in the late 90s didn’t have to buy expensive mainframe hardware to run Unix software.
The issue with Linux on the desktop, and especially the laptop, in the pre-systemd days wasn’t the init system. It was the lack of quality drivers.
Now I’m not saying that systemd hasn’t brought improvements over sysv. But to say bash worked badly on laptops but fine on servers is just silly. That’s simply not how the technology works at all.
And I don’t need to read some promotional piece from Redhat to know this. I’ve been running Linux on desktops and laptops longer than many adults have been alive. So I’ve lived through these massive ecosystem changes and have a first hand account of life before systemd.
Actually yes, that's why they did stop working. Laptops regularly change hardware configuration. Desktops less so. Back when "local ISPs, newsgroups and so on and so forth" had desktops, they never changed hardware configuration while running.
RCS is really the only thing I truly am annoyed by with rooted devices. If GrapheneOS can build something open that works we should be able to rip it apart and get it to work without passing play integrity.
RCS already works on GrapheneOS via Google Messages using sandboxed Google Play. We have an ICC authentication toggle for granting the required access to Google Play services. We want to provide our own implementation within our Messaging app to replace Google Messages and then we want to provide an alternate backend not depending on sandboxed Google Play, at least for carriers with their own implementation.
This is rough when you have lots of weird one offs. Strange trrs->rj45 for programming a radio you still use but haven't reprogrammed in 10 years; does that go in "generic serial stuff" or "things you want to keep but haven't used in a long time" (right next to the 13w3 -> 5 wire component cable for the sparc in the other corner)
Hopefully, but it's good to have it disabled as well so that your system isn't screwed by the next zero day and to help cover you in case the fingerprinters manage to find a technique to get identifying data from WebGPU that your ad-blocker hasn't accounted for. It's a constant arms race after all. Hopefully the ad-blocker is still feeding them randomized data even with it disabled, but otherwise other randomized data points should keep your fingerprint unique even if a lack of WebGPU support stays consistent.
Which makes Arizona an interesting place to place any new builds of any sort of data center. They’ve been talking about the scarcity of resources there for years, and it’s currently in an escalating tailspin of abundance. Power is cheap as hell there, but once the water dries up… things might change quickly.
There's also a power generation water cost though!
Something like 500g/MWh for gas/coal/nuclear (~70% of power in AZ), so a huge xAI datacenter (Colossus 2, ~1 GW/h) would use ~700 MW of this type, or ~350k gallons of water an hour, which would be 0.2% of the Colorado rivers flow rate last year.
Pulling recent data from the EIA, of the roughly 10,000 megawatts of new power capacity installed in Arizona between 2023 and 2025, 50% is batteries, 40% solar, 6.5% wind, and 3.5% gas. Now, most solar and wind plants rarely if ever hit their nameplate capacity, but it’s pretty clear the large majority of new power generation isn’t consuming water.
https://www.eia.gov/electricity/data/eia860/
Does that change the math above if they're tied into the grid?
If they're tied directly to the renewables (Meta is doing this in some places), then true, not a technical increase. But you could still maybe claim they're instead preventing the equivalent reduction on average/grid (and, say, decommission of some of that coal). I suppose that's a separate point.
If it’s truly separated (no interconnect agreement) or generation capacity is below 1 MW, it won’t show up in EIA data, yes. Rooftop solar is also not included in the data for that reason.
It's the type of situation where that amount of water use isn't going to move the needle very much even in the desert, but building thermal power plants there there is still kind of silly because a) deserts are generally well-suited to solar, and b) you could also build thermal power plants in places like the midwest where that amount of water use is totally irrelevant.
Ok, those are truly closed loop. As in, they use ambient cooling or active chillers. I've seen too many cooling tower sites described as closed-loop because the internal system is.
Alaska’s land is pretty rugged and hard to build on. It would be interesting to hear from someone who works in the industry why the Northern Interior states like Montana, North Dakota, and Minnesota have fewer data center buildouts than Texas though.
Sure, but it seems very reasonable to expect some co-hosting of latency sensitive tasks, especially with some low hanging thin client fruit, like cloud gaming and the like. I've been very happy not burning a thousand watts of $0.45/kWh power locally, for my AC to force out of the house, to run blender.
I'm all for supporting quad9; but what if we just disable dnssec instead, it really solves nothing and continued support of it just makes it show up in compliance guides unnecessarily.
Just just seems like a reason to have a truely distributed DNS system that is censorship resistant. The complaints presented should be _unfixable_ since they are a feature, not a bug.
There is no such thing as unfixable. It's just kicking the can down the road. Look at how email devolved because of the features that made spam "unfixable". I would like dns not to go down the same path, which seems all too likely if nothing is done. Already most corporate networks are blocking most "new" domains. It's only a matter of time before new domains you buy are essentially unusable.
reply