Hacker Newsnew | past | comments | ask | show | jobs | submit | SpaghettiCthulu's commentslogin

You can trivially install another launcher without that search bar and disable nearly all bundled apps on Pixels. Show me how easy it is to remove all the ads and bloatware from Windows.


Note how you said "disable" :) . That's because it is impossible to remove bloatware from Android, praise be Google. I also have Chrome disabled on my phone for many years, but it is there still.

And regarding Windows, first I want to tell that I'm not a fan of recent MS trends too. Second - I personally never had a single ad on my Win10 and current Win11, so I wouldn't know how to remove those :) . And third - to remove bloatware just uninstall it from the Programs and Features, like OneDrive or Office. LLM can be disabled in Settings. Some bloatware will remain due to deep integration, but that's the same issue as with Google or Apple. For instance I may not want to see Stocks app on iOS, but that's not my choice to make apparently :) .


What benefit would there be to uninstalling those bundled apps entirely vs disabling them? It's a nice goal to aspire to, sure, but does it really matter?


> successfully killed ZLUDA

Did they? Sounds like AMD did that[^1] and that the project is continuing based on the pre-AMD codebase[^2].

[^1]: https://www.phoronix.com/news/AMD-ZLUDA-CUDA-Taken-Down

[^2]: https://www.phoronix.com/news/ZLUDA-Third-Life


Unless ZLUDA can show that it is a clean room re-implementation from a spec without contact with the CUDA libraries, it would be a bad place for AMD to place themselves. That could be reason enough to retract voluntarily before any bad press. Such a thing is possible but likely much harder than Compaq re-implementing IBM PC BIOS.


> "A complete rebuild was necessary to ensure the website meets modern security, usability and accessibility requirements for the millions of Australians who reply on it every day," a spokesperson said.

I guess those "usability and accessibility requirements" don't include being usable without JavaScript.


Unless you think the same backdoor is hiding in AOSP, you can just check the diff and some extra lines for context.


People in this thread are very explicitly claiming that Android and iOS are backdoored, yes.


You really want an LLM hallucinating that everything is ok and turning your air back on? Or hallucinating that everything was always ok and not turning your air off in the first place?


Hallucinate off is fine then send message to me with decision criteria.


Source?


> When you reach out to one of your recovery contacts for help, you will share a code with them. They will get an email or notification and can confirm it’s really you by verifying that code, helping you securely regain access to your account. While you should choose someone you trust, rest assured that your recovery contact will not have access to your account or any of your personal information.

What additional verification will be required to regain access to your account?


Would be safer to use GrapheneOS and distribute these apps on F-Droid, using a custom repo if the main one won't allow them.


I'm not sure it's safer if you consider their tight dependence on Google, https://news.ycombinator.com/item?id=45208925


It's not just Android. I've encountered frequent broken gradle caching when using Kotlin outside of Android and when using Fabric for building Minecraft mods. In my experience, the only solution is wiping the user-wide gradle cache. Maybe it's a gradle issue or maybe it's an ecosystem issue (i.e. gradle plugins not respecting Gradle's cache semantics). Regardless, it does not reflect well on Gradle that such issues are so widespread.


From TFA:

> The primary use case in mind for parker is on the machines with high core counts, where scalability concerns may arise. Once started, there is no communication between kernel instances. In other words, they share nothing thus improve scalability.


Curious what benefits this would have vs the usual virtualization? VM’s are the typical strategy for subdividing machines with high core counts into multiple kernels, and seems to work well enough?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: