> What explains this need to put things down because it's not glibc, systemd and GNOME?

all of those 3 projects are *constantly* criticized and put under scrutiny for their design choices, so, i have no idea what you mean by that

because a) you completely ignore anything else i say, including the two times i said that third world countries don't get pixel phones, specially not cheap ones, and b) because you said it yourself:

> > firstly, don’t see this as an attack on GrapheneOS
> Okay, but that's how we see it.

Literally. The double standard is ridiculous.

It's been years of GrapheneOS publicity/social media activity making the maintainers look self-centered and ignorant. I have to tell anyone I recommend GrapheneOS to not look at your social media activity. If you can't take criticism, how are you going to ensure security through peer reviews? How will users be able to trust your ability to work together to make secure software when this is how you treat people who disagree with you?

Stubborn, self-centered people are a risk factor in InfoSec because these attributes indicate closed-mindedness. You have to work on this if you want people to (continue to) trust you with this project.

— A concerned long-time GrapheneOS user

Sensitive content Reveal/hide

Now I miss my Moto phone more. Damn bad boy lasts long but I lost it

@izzy

It was your point that Motorola is the partner because they want to make money. If the people are only able to buy their phones after some others already did and now resell them, I don't See how they profit. People buying the high Ende devices for Graphene may exist AS well but in WhatsApo rate

@King_of_Ooo @lumi @alexia

> systemd -> dinit or s6

Lots of these are giving up even more security features.

> hardened_malloc, malloc-ng, or mimalloc-secure

These aren't the same classes of allocators at all. Neither the musl malloc or mimalloc is a hardened allocator. mimalloc is performance focused and musl's is focused on low memory usage.

> What are your thoughts on what to do in case the day comes that Google kills AOSP?

What about when IBM decides to kill systemd, GCC and GNOME?

@GOKUSHRM Our partnership is Motorola is not exclusive and we're fully allowed to partner with other OEMs. However, we don't currently have the resources to partner with additional OEMs and it will likely be a while before we do.

Partnerning to make smartphones with a company which recently discontinued their smartphones doesn't sound workable. The point is also mainly getting an OEM to raise their security to meet our requirements rather than getting an OEM to sell devices with GrapheneOS.

doing PGO on a development build (considering the guide is meant for developers) is insane IMO

that's something one would do on their final fully optimized build, not for development, and specially not if the need to debug anything in native code is there...

from what i recall in my encounters with googlers: it's pgo.

from my own experience on gentoo lto adds around 30% memory pressure and pgo adds around 50%, compile time is mostly unaffected with lto but pgo quadruples it.

parallel builds and LTO stuff, i assume

meaning you could run with less memory, by reducing the amount of parallel builds, except that would make the already long 6 hour build time increase close to exponentially

so 64 gb for 72 build processes doesn't seem super unnatural but 64 for 6 is weird.

it's probably fine with 8 to 16 on 6 core.

note that, as i mentioned on the thread before, back in 2019 i tried to build it on a 7th gen i7 (so 4/8 c/t) with 16 gigs of ram and a sata ssd, after 3 days of non-stop building, i gave up

and that was when the minimum recommendations were still 32gb of ram

@King_of_Ooo @lumi @alexia

What about when IBM decides to kill systemd, GCC and GNOME?

systemd

Between GNU Shepherd, supervise-daemon and runit?

GCC

You'll have to explain why/how IBM owns GCC. Fairly sure it's an actual FSF project.

GNOME?

RIP lol

Other than the accessibility stuff most of it I don't care much about, and with the ensloppification going on & Red Hat apparently insisting on it, it might well die anyway.

What are your thoughts on what to do in case the day comes that Google kills AOSP?

This however has real chances of happening and already has a largely closed development process with no community.

Which means it doesn't even need a poison pill contributor agreement, all the necessary rights are probably already in Google's possession for malicious license changes.

Not to mention that the main useful part of Android, the drivers & their documentation, aren't even included anyway. Everything else could be replaced by something better with some work.

@King_of_Ooo @alexia @lumi So, how many of those community projects aren't simply downstream like the Mozilla Firefox ones?

How many are actually credibly in a position to take development over entirely with a dead upstream?

@lispi314 @King_of_Ooo @alexia @lumi

> You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.

Don't know what you're talking about. You're one of hundreds of people.

> The overwhelming majority of the BSD tooling

It has little to do with the desktop software stack. That increasingly only has an incomplete port over to BSD with a growing amount of hacks. It would just roll it back even further.

@King_of_Ooo @alexia @lumi You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.

The overwhelming majority of the BSD tooling that isn't systemd could be ported with a modest effort if systemd died. Note that I linked daemon supervisors earlier, because session managers and init systems are a lot easier to come by.

edit: Ah, my bad, I confused the subthread. You did ignore it and replied to the prior post.

By the way, I'm still very interested in your input on this part.

I would hope that such isolation is part of the GrapheneOS safety requirements.

@greenpete @bobkmertz @joe9nf

@bobkmertz @greenpete @joe9nf That was most likely the modem and in some early mobiles there was zero isolation preventing the modem from simply reading all the memory bus.

(The modem should be understood as a blackbox device at the mercy of hostile infrastructure providers & "authorities", it is attack surface.)

I would hope that such isolation is part of the GrapheneOS safety requirements.

If they #Motorola could add #LoRa or something similar that could be a game changer.

They would offer something that other companies don't, while there is demand from users.

It also brings privacy advantages as it makes it easier to communicate undetected from cell towers. People are starting to roll out networks covering wide areas.

In addition to that, it adds an element of resilience where people could continue to communicate even when cell towers are shut down. This is especially important during national disasters and governments overreach shutting down internet access.

@lumi@GrapheneOS

TL;DR: Yes.

@lumi@GrapheneOS

Well, as degoogled as using an OS maintained by Google gets

@luana Yes, that's part of our hardware requirements:

grapheneos.org/faq#future-devi…

Whether they'll be sold at retail with GrapheneOS preinstalled as an option isn't a question we can answer yet. It mostly comes down to Google's requirements and the extent to which those can be worked around or pushed to be relaxed.

@ferricoxide @luana No, it's a much different feature than the incomplete implementation for desktops. The entirely of the firmware and operating system are cryptographically verified with downgrade protection. The secure element is used to store the version metadata for downgrade protection for the OS and efuses are used for the firmware portion of it. It's fully integrated with the A/B update system with automatic rollback until reaching the home screen successfully.

grapheneos.org/install/web#ver…

@GrapheneOS Go for it. You will succeed when there are, let's say, three phones from affordable to high range.

The future: When you are supporting a lot of Motos, integrate another brand (Asus?) and finally get rid of the Pixels.

This is a premature joke for the 1. April, right? 😳🤔😂🤣

Choosing a company like Motorola with it's owner Lenovo behind it for the reasons of privacy and security isn't beyond a good idea but pure hypocrisy and a punch in the guts for all of the supporters of GrapheneOS in my opinion. 🖕

Greed ate brain, happened again it seems. 🤮

#GrapheneOS #Motorola #Lenovo #Privacy #Security #Hypocrisy #Joke

@JamesDBartlett3 @lispi314 @a53bdb @lunareclipse I agree.

I consider the USA as the premium example for the latter. 😉