Hacker News: surajrmal

New comment by surajrmal in "Redesigning source control at Anthropic"

surajrmal — Mon, 19 Oct 2026 14:53:07 +0000

The same way many companies do I would assume, lots of automated config changes.

New comment by surajrmal in "Linux 7.3"

surajrmal — Mon, 19 Oct 2026 13:57:22 +0000

Which will just put pressure to improve the testing situation, not necessarily change stance on AI written patches. In fact AI is quite good at catching issues and root causing them back to recent changes so they could automate that journey a bit better as well to fill in any gaps not caught at review time.

New comment by surajrmal in "Shipping JPEG XL in Chrome"

surajrmal — Wed, 07 Oct 2026 13:04:59 +0000

It's interesting how different theories come about when there is a lack of information and a high degree of preexisting bias. Reality is a lot simpler - it wasn't deemed worth the cost of addressing the security problems in the existing library so someone chose to abandon the format. However as industry adoption increased and a newer safe library appeared, the decision was changed. Also, note that while Google developed the new rust library, it wasn't the chrome team who made the investment.

New comment by surajrmal in "How to speed up the Rust compiler in September 2026"

surajrmal — Wed, 07 Oct 2026 05:39:03 +0000

I feel like there is an assumption here that solving the problems described will result in a worse outcome for the average rust user, but I'm not sure that's the case. Perhaps the existing way of compilation makes sense for release mode, but a different tact could be taken for compilation modes which are optimized for developer productivity.

I agree with the sentiment that you can't solve for everyone, but if a problem is prevelant in your userbase, it's worth optimizing for solving it. Not every tool will be used the way it was designed to be used.

New comment by surajrmal in "Pixel 11 doesn't yet meet the GrapheneOS security standards and may be skipped"

surajrmal — Mon, 05 Oct 2026 14:35:55 +0000

MTE requires several things to work well. Notably there is some missing hardware believed to be necessary for MTE to be performant on the pixel 11.

In terms of mitigation of UAF, a great deal of new code written for Android userspace these days is in memory safe languages such as rust. Also, a lot of testing with instrumented code sanitizers is still done before release. We don't know how much risk MTE actually mitigates.

New comment by surajrmal in "Pixel 11 doesn't yet meet the GrapheneOS security standards and may be skipped"

surajrmal — Mon, 05 Oct 2026 14:29:43 +0000

There are several peripherals running their own OS. Those have their access to RAM limited by an iommu and they have no direct access to the primary storage (they may have some local ROM storage for firmware). If you're asking about the other OS that runs on the application processor such as the bootloaders, trusted firmware, trusted os, etc, then no, those have a superset of access to what the primary OS running on those cores have access to. This is by design.

New comment by surajrmal in "GrapheneOS has fixed the Android 17 QPR1 kernel performance regression"

surajrmal — Sat, 03 Oct 2026 16:27:34 +0000

The model for Android is that the OS is provided by the OEM. They work in partnership with Google. GrapheneOS tries to work against this model by not partnering with the OEM on supporting their hardware with its OS. Ultimately that's not sustainable given the dynamics of the ecosystem. This is why they are moving to a model where they do work with an OEM directly. These sorts of problems will subside once that happens.

You could argue that the current ecosystem dynamic is not great for the longer term, but it will require a change from the OEMs to enable something different as they are the ones actually in control of the situation.

New comment by surajrmal in "GrapheneOS has fixed the Android 17 QPR1 kernel performance regression"

surajrmal — Sat, 03 Oct 2026 14:03:12 +0000

I'm not sure that's the reason a minority user group is using alternative ROMs. They have always been niche, even before the play integrity API took off.

New comment by surajrmal in "How to speed up the Rust compiler in September 2026"

surajrmal — Fri, 02 Oct 2026 14:21:13 +0000

Arguably it is a rust problem. Rust can be improved to reduce the need to do as much manual maintenance of crates dynamics to allow for faster build times. The "you're holding it wrong" answer is not a good perspective to apply and I am surprised to see a prominent member of the rust community using it.

New comment by surajrmal in "How to speed up the Rust compiler in September 2026"

surajrmal — Fri, 02 Oct 2026 14:01:43 +0000

Worktrees can work with a shared build cache.

New comment by surajrmal in "How to speed up the Rust compiler in September 2026"

surajrmal — Fri, 02 Oct 2026 14:00:34 +0000

It has 1.8 million lines of rust. That compilation time seems close to what I'd expect at that size. If you want something faster you should focus on distributed build caching rather than speeding up the compiler. Also note that crates are effectively equivalent to a single file in c++ as it's the compilation unit. This is similar to compiling 2k files that average 1k loc each in c++. I'm sure it's much worse when you account for macro expansion and generics.

New comment by surajrmal in "AX – Google’s Open Agentic Orchestrator"

surajrmal — Mon, 21 Sep 2026 14:59:11 +0000

KYAML seems eerily close to json5.

New comment by surajrmal in "AX – Google’s Open Agentic Orchestrator"

surajrmal — Mon, 21 Sep 2026 14:56:38 +0000

There is an assumption that AOSP is how OEMs receive Android updates from Google. However I am not sure that is the case. GrapheneOS is perhaps a minority player due to lack of hardware which they can use to get into a partnership agreement and advanced access.

New comment by surajrmal in "AX – Google’s Open Agentic Orchestrator"

surajrmal — Mon, 21 Sep 2026 14:49:33 +0000

I don't think that phrase means what you think it does. That only makes sense when there exists an open standard which a company builds an implementation for. Android was built from scratch and there was no standard.

New comment by surajrmal in "Android 17 is the first since 3.x to add new APIs without releasing to the AOSP"

surajrmal — Sun, 20 Sep 2026 03:43:42 +0000

The scale of engineering to compete with Android is an order of magnitude or two larger than that necessary to compete with those other products you mentioned. Not to mention the challenges of getting the developer market to follow you to your fork. It seems like any phone vendor even capable of giving it a go is okay with the current arrangement. Chinese firms can definitely do it and I guess Huawei has, but that's not entirely relevant to Western markets.

New comment by surajrmal in "Android 17 is the first since 3.x to add new APIs without releasing to the AOSP"

surajrmal — Sat, 19 Sep 2026 03:34:24 +0000

There was a split world for a long time even before the more recent changes because of the need to hide secret new features or products from the general public. It was always a tricky arrangement. They just decided one day that there wasn't a lot of folks contributing that lacked access to the private repos, so they might as well just switch all development to occur in that place. Honestly, it's somewhat rationale. If there was a significant number of folks contributing to Android without such access I'm sure that wouldn't have happened. We didn't lose as much as folks think we did given the code drops from the private repos still happened even previously.

New comment by surajrmal in "One Year of Sponsored Servo Development"

surajrmal — Thu, 17 Sep 2026 14:10:28 +0000

I'm curious why you care about whether or not they spent time and effort to write those components themselves. Isn't that their choice as the authors? How does it materially affect you or the product experience? From my vantage point, I love the idea of having even more options as it will create competition, making all sides better for it. Having a singular dominant player in any space (whether it's a browser, kernel, or library) is something we should try to avoid whenever possible.

New comment by surajrmal in "Nvidia announces native GPU programming in Rust"

surajrmal — Thu, 17 Sep 2026 13:06:18 +0000

They don't need to do that to sell their hardware so why would they do that? On the other hand, they have strong incentives to not give you that level of access and information. The only way this will change is by having some disruption by way of a competitor who sells hardware with that feature as being a major reason why it takes off.

New comment by surajrmal in "The Google Play app review process now regularly takes longer than a week"

surajrmal — Wed, 16 Sep 2026 13:09:05 +0000

Security at its core comes down to trusting the supply chain that provides the software that runs on your hardware. There are many alternative secure supply chain models, but ultimately users often are incapable of making great choices on what is trustworthy. It does generally make sense that the OS vendor needs to play a key part in helping ensure trusted parties are involved in the supply chain.

Comparing phones to PCs isn't a great comparison because PCs don't have a great track record and the amount of personal data and ease of installing lots of apps is quite different. Of course the current arrangement is far from perfect, but acknowledging the problems it's trying to solve is an important step towards trying to find a solution that is better.

New comment by surajrmal in "Reverse engineering my e-scooter and rewriting the firmware in Rust"

surajrmal — Sun, 13 Sep 2026 16:28:15 +0000

Having been on the flip side of this divide in the past, there really are a lot of potential safety and reliability problems when using random third party versions of components. While I'm sure there are strong financial incentives to constrain supply, there are also some other strong reasons as well.

Also it's very expensive to actually make an ecosystem compared to a close one. The best way to incentivize manufacturers to do it is by creating a competing product that is open and having that differentiating feature drive sales away. That's generally the approach that works best.