Thread

1. mmooss · 1790974594 · focus · HN ↗

   [dead]

   1. Dezvous · 1790976821 · focus · HN ↗

      >Just zip it, be professional, focus on what you are doing and not on others.

      How do you propose they "focus on what [they're] doing and not on others" when their entire project is dependent on other's (Google's) work that directly impacts their own users? There's nothing about this blog post that is unprofessional. GrapheneOS released a patch for a rather severe performance bug, which is outside the scope of their normal work, so they provided context into why they made the decision to do so.

      1. andrewaylett · 1790978533 · focus · HN ↗

         Look to "HugOps" as inspiration: when someone else is having a bad day, offer them a hug rather than running them down.

         The article uses phrases like "completely broken", "awful", and "<delay> wouldn't be a surprise". Which might be true but it's not helping.

         1. Dezvous · 1790995951 · focus · HN ↗

            Those phrases are true and they helped by making a patch, which Google will most likely end up merging. So what's your point? Should GrapheneOS blogs treat Google as if they're an individual with feelings having a bad day? The same Google that routinely and deliberately hampers the development of GrapheneOS and other similar projects?

            Google pushed out bugged code ostensibly breaking millions of phones, mine included. They have the means to fix it in a short amount of time like GrapheneOS devs did, but they won't do it, so GrapheneOS took the initiative.

            1. andrewaylett · 1791026356 · focus · HN ↗

               No, we shouldn't treat Google like an individual, because it's not. But we can (and should) be mindful of the individuals who make up the various teams within Google.

               That's part of the motivation behind HugOps: the people working on fixing a thing are only rarely the people who are responsible for the system that caused the breakage.

               1. grapheneos · 1791058776 · focus · HN ↗

                  Individuals at Google working on Android are ultimately responsible for Google's years of attempts to harm projects based on the Android Open Source Project. That includes Google coercing their OEM partners to sign illegal anti-competitive agreements, pushing the illegal anti-competitive Play Integrity API and breaking many public commitments to open source along with the promises they made to sell Pixel phones.

                  South Korea and multiple other countries have already found the Google Mobile Services licensing agreements to be illegal, so it's an objectively true statement to call it illegal. Samsung has been largely freed from the restrictions due to the court decisions in South Korea combined with their market share, which is good, but also incredibly unfair to other Android OEMs.

                  GrapheneOS was initially collateral damage for Google's anti-competitive behavior but in the past couple years they've shown they feel threatened by us and are very actively trying to hold us back. It's not everyone at Google doing it but it's enough of them including the people in control.

                  1. andrewaylett · 1791067767 · focus · HN ↗

                     Right. But riffing off a response that's a cousin of this one — what are you actually trying to achieve with your writing? And I should also note that I agree with you, in substance if not in style.

                     I'd suggest that Google aren't your primary audience for this kind of post: it's folk like me, who are quite keen on the idea of GrapheneOS but don't actually use it yet (I actually bought a second-hand spare phone last week with the ulterior motive of trying GrapheneOS on it, we'll see...). What do you want your average reader to think about you, from reading what you've written?

                     I should add that this post (that I'm directly replying to) comes across to me as very much more appropriate than the original blog post, even as it's in many ways a lot harsher. It's putting Google's behaviour in context, rather than drawing comparisons between your own abilities and their poor performance.

                     You don't need to drag Google down in order to look good; there are many reasons why what Google (and especially their management) have done is bad for society (and not just for you) and also many reasons why what you're doing is excellent on its own merits, not merely compared to Google.

                     1. grapheneos · 1791074452 · focus · HN ↗

                        It was an announcement on our forum for our userbase to explain why the last update introduced major issues with lag, how that happened, that it wasn't specific to GrapheneOS and that we were highly prioritizing working on it. Our release fixing it was pushed out to our Alpha channel yesterday, reached Beta early today and is now in Stable. We had to make an announcement about this because it was heavily impacting perhaps 1/5 people and was noticeable by many more people once they were made aware of it even though they weren't heavily impacted. Many users were complaining about this after there had been several days for memory pressure to start getting triggered for a much higher proportion of users.

                        There were a small number of complaints prior to us moving the release introducing the issue to Stable. There were very important security updates in the updated firmware/driver code and we decided we needed to release it despite that. It took several days for most people's setups to build up enough memory usage to start triggering it. It started impacting a lot more people after a while and we realized it was a severe issue we had to address ourselves instead of waiting for Google to do it.

                        Google likely had the same reasoning for pushing it out to people to get many other issues including security bugs fixed despite a major known regression. We did not have time to avoid the situation in advance. We had to either delay driver/firmware security updates or ship it and then fix this afterwards. The problem is that it typically takes them at least around 4 to 6 weeks to ship a fix for even a critical issue. They've sometimes managed to do it in 3 weeks in extremely critical cases. It's unusual for them to move that quickly and it takes them longer to do kernel changes userspace ones. Once we figured out the issue was, it was quickly fixed and we started builds for a release in the same day.

                        It takes a long time for us to build a release for 21 different devices despite having build machines for it due to each having a specialized build with only what they used and their CPU architecture, etc. and we actually need 42 builds due to security preview releases. We plan to make incremental builds reliable enough to use those for production but it requires great care and potentially ongoing CI testing of reproducible builds to make sure incremental builds haven't regressed. If memory wasn't so expensive, we could buy a bunch of hardware to upgrade or replace our existing 4 local build machines for official releases.

                        1. mmooss · 1791091546 · focus · HN ↗

                           > It was an announcement on our forum for our userbase to explain why the last update introduced major issues with lag, how that happened, that it wasn't specific to GrapheneOS and that we were highly prioritizing working on it.

                           Whatever your 'reasons', the consequences are the same. Of course you know that "announcement on our forum for our userbase" can spread much more widely than that.

                           To lead successfully, we can't just do what we want and ignore the consequences. A leader's job is to get the best consequences.

Unofficial Hacker News client; not affiliated with Y Combinator.