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

Why not flutter?

See the first post, they have 6000 engineers.

Their reasoning’s and opinions on anything are useless to compare to almost anyone.

We’re using Flutter successfully and love it. I don’t have 6 engineers to throw at Native, let alone 6000.


The people who are going to be successful in the coming economy is the ones who can channel all the knowledge and experience of an llm without shame. If you are smart:

"... in the style of a my writing"


I've been doing that. It helps that I have a substantial human writing corpus to draw from. Results are still mixed. Models simply can't resist adding some LLMisms. Pangram still detects some of it but not others, and also misdetects some of my actual writing as AI generated.

Honestly, I'd rather the shame and hate just went away instead. It's seriously exhausting and I'm starting to feel tempted to just give up and either start using AI more heavily or stop writing altogether.


Directed Panspermia

I hope its good, I wont test it though

I don't use it. I chat about all kinds of random things and I don't want to risk memory that is irrelevant being injected in my random sessions.

0 outgoing, nobody knows numbers anymore and even if you could look it up you won't punch numbers like its 1992.

With that said, amazing project. super cool that people can call in


Is it possible that people don’t realize you can make free calls? Perhaps they think you need coins, which they don’t have on them.

Similar to interactive installations in museums. People are afraid to touch things in museums. You really need a big sign to tell them it is the purpose to play with it.


It has changed a bit in recent years, but there's still only very spotty cell service at Burning Man. Enough people can figure out how to look up a phone number that this phone still dials out thousands of times during the week.

The bigger problem for this project is because of phone spam, fewer people will answer calls from unknown numbers, so a lot of those calls go to voice mail.


What, MTE is such a promising tech and for security and now that we need all security we can get. WTF this is terrible development. You cant go backwards when the world needs getting even more secure.

Such a shame. Google themselves barely utilised it in their stock builds. I wonder if there is some silicon or development overhead they decided to cut.

I'm optimistic about the Motorola partnership and when my 9 Pro is EOL I'll definitely look at how that's played out.


Google likely cut MTE to reduce the die space required by CPU cache. It saves them money on a feature they never deployed by default and only used for a few processes as part of Android Advanced Protection Mode (AAPM) without enabling it in the Linux kernel. Their security team should have gotten it deployed by default for a large portion of the OS by now and then it would have been much harder to justify removing it. The small performance impact of asymmetric mode is irrelevant for the vast majority of the OS and it can also be used in the near zero cost asynchronous mode. We use synchronous in the kernel for security reasons but they didn't have to do that.

It's a completely different story for GrapheneOS where it means losing one of the main kernel and userspace security protections. This is one of the only ways we can significantly harden the Linux kernel with existing security features. The Linux kernel has always been a huge security liability for Android and AI models are making that much more obvious to everyone.

Google will likely end up heavily using MTE in the future. Pixel 11 devices won't be able to benefit from it. They're at the start of 7 years of updates but they won't be getting the benefit of future updates enabling MTE. Pixel 8 and later will benefit from Google likely expanding use of MTE for AAPM and eventually beginning to use it by default. It's unlikely Google will stop working on expanding MTE due to the Pixel 11 hardware decision. Multiple other OEMs are interested in MTE for devices made for businesses and governments even if Google decided it wasn't worth the cost for Pixels.


Ironically the recent CVE that's being used to root Android phones (Ghostlock) running GKI images is mitigated by MTE.

If there will be a GrapheneOS image for the Pixel 11 without MTE, could that open the door for GrapheneOS on a lot more phones that support AOSP?

We don't plan to make official GrapheneOS releases for any more devices without MTE. If we decided to provide support for the Pixel 11 series, it likely won't be branded as GrapheneOS to make it clear it isn't on the same level.

It would be inconsistent to require Motorola to provide MTE support and then to support the Pixel 11 without it.

There are no phones directly supported by AOSP. Motorola is helping us support their devices and port our features to them. We have to do an immense amount of work on it ourselves for Pixels and already did a lot of it for the Pixel 11 devices. Other devices are missing more than MTE.


Regarding the differentiated branding, I've been hoping for a GrapheneLite for many years now.

Regarding direct AOSP support, there are many devices that work fine with just the generic system image, which I'd count as direct AOSP support.


As far as I understand, broad device support is a non-goal for the GrapheneOS project. They are striving for decent security/privacy rather than wanting to attach their name and resources to mediocre standards.

I believe nothing prevents other individuals and organisations from building what you're suggesting with GrapheneOS code and ideas.


I would argue that "works fine" != "direct support" when discussing vendors and platforms. Support is a commitment signal, not just a technical capability.

The supposed "security team" is busy fighting Google engineers connecting to internal systems to do their work. E.g. somebody figured how to control the coding AI agent from their phone -- red alert, ban all access from phones to AI for everybody (even with corporate accounts).

You say that like it's a bad thing. If I am trusting Google with all sorts of personal information, I expect robust access controls to data and systems

Weird omission then... Seems asinine...

I don't understand much from MTE/Android or MIE/iOS but the explanation is also confusing when:

- They claim Apple did a great job integrating MIE in iOS - iOS doesn't encourage to opt into MTE ... Apple's docs warn developers of performance and stability issues

So it seems like even for iOS, this special security feature is only available for Apple own iOS app (at most?).

Then also:

> Even Signal doesn't opt-in. Our approach enables forcing using MTE in the standard allocators regardless.

So does that mean that Signal and any other apps are enrolled in MTE on Graphene?


iOS uses MTE for nearly all of the important parts of the OS. It uses MTE within the kernel and for a substantial portion of the base OS processes. They focused on deploying it to the most security relevant processes first but it's deployed for a large portion of the OS beyond those. Apple has done a very good job protecting the OS with it. They've done a very poor job getting the app ecosystem to adopt it.

Android has more app ecosystem adoption than iOS due to having a better open source app ecosystem where GrapheneOS users have asked apps to enable it by default. Many GrapheneOS users are also force enabling MTE for user installed apps via our recommended toggle for it. Those users are reporting invalid memory access to developers via our dedicated notification system for invalid memory accesses it catches. For Android app developers, not opting into MTE doesn't mean their app won't be used with MTE due to GrapheneOS.

GrapheneOS uses MTE for the kernel and nearly every userspace process including all the base OS apps. We've had to fix many upstream Linux kernel and Pixel kernel driver bugs found by MTE. However, we aren't trying to fix the Pixel userspace drivers code ourselves so we have a few userspace processes excluded from MTE caused by userspace driver library/service bugs.

We recommend users enable our toggle for enabling MTE by default for every user installed app not explicitly marked as incompatible in our compatibility database. GrapheneOS has user-facing notifications for invalid memory accesses caught by MTE providing a traceback to share with the app developers. Users can use the per-app toggle to work around it if it makes an app unusable. We take the same approach for other aggressive exploit protections provided by GrapheneOS. Exploit protections with only rare compatibility issues are enabled by default for apps with a per-app toggle to opt-out and no toggle for the global default.


I see a significant difference between making a security feature available but opt-in during a teething phase, and removing the feature altogether. Am I missing something?

This isn't terrible development, it's simply that GrapheneOS devs can't do miracles They can't just continue supporting phones if they have security downgrades, especially if it's an important feature.

I think they mean "this is a terrible development" in the sense that this is terrible news/turn of events. They arent criticizing GrapheneOSs software development.

Does anything matter if it's illegal or not when it comes to the current government? This is not a flamewar im interested from a practical perspective if things like this has any effects at all in practice.


IDK.

I'm seeing the gov capitalize on the lag time of the US judicial system reacting authoritatively to illegal gov behavior.

To me this is a continuation of a Win At All Costs strategy.


It de-risks defense contractors working with Anthropic on other projects. The most aggressive interpretation of the blacklist is that Lockheed Martin was not allowed to use Anthropic to develop their own products, and that's not on the table anymore.


Yes, Kilmar Abrego Garcia is back in Maryland, as one example.


Government has three branches for this reason, so yes everything matters if it is illegal.


what are the potential consequences then

Have generative AI create the music and then become a cover artist for AI generated music. No one will notice. Lots of musicians are cover artists because perhaps they are skilled in their playing instruments and or singing but have a hard time coming up with good music. So instead let AI come up with the music and just copy it and make it yours.


Do you think people that use machines to generate music have the technical skills to be a cover artist? (I suppose you mean with real instruments)

The only people salivating at generative AI are those that do not have the skills to create without.


Dirty secret of the industry, lots of producers and musicians are using AI to "brainstorm" songs, then sampling from them or performing slightly shined up versions of them. Sort of like musical photobashing.


Performance is not the same as original creation, so yes, I think that's very possible.


yikes ... assuming you hate MIDI too


Generally people hate plagues. For instance I remember hating rock ballads in the early 90s. It all depends how much of a threat to civilization the thing is, currently, but later on in retrospect it becomes harmless and amusing.


MIDI isn't generative AI.


as someone who used Gerrit for a year: No


As someone who used Gerrit/still uses Gerrit for more than 3 years... also no.


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

Search: