The flip side of this is filtering for "US Persons" (non cleared, but citizenship, located in the US) for remote work at the Sr/Staff level. The amount of BS that I get is astounding.
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.
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.
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.
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.
reply