Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Temptation of the Apple: Dolphin on macOS M1

dolphin-emu.org

Post reply on HN
Print view View original

231–240 of 390 posts

Re: Temptation of the Apple: Dolphin on macOS M1

#231

Post by dstaley »

djrogers wrote: post #185
xrd wrote: post #124

Where is the Linux ARM equivalent laptop? When I read about Pine laptops, it never seems like they tout the amazing performance like the M1.

> Where is the Linux ARM equivalent laptop? There isn't one. Apple's silicon team is at least 1-2 years ahead of all the other ARM vendors when looking at mobile performance, and none of those vendors are even trying to do anything in the desktop space (yet).

Qualcomm has released several ARM-powered Windows laptops, and just announced today a desktop-form-factor Windows Dev Kit powered by the new Snapdragon 7c platform.

Re: Temptation of the Apple: Dolphin on macOS M1

#232

Post by fouric »

threeseed wrote: post #32
jeroenhd wrote: post #24

It's clear AS is a great advancement in general computing, but every piece like this reads as "the hardware is amazing, and it's totally worth it to work around these arbitrary software restrictions". This performance would've been available on iPads years ago if it wasn't for Apple's blanket ban on JIT and the likes. Apple is one of those companies whose hardware I'd love to have if it wasn't for their software and…

Apple’s blanket ban on interpreted code is not arbitrary. It is there to prevent apps circumventing the review process and security model ie. apps pretending to do X during the review process and then doing Y when in use or obfuscating their use of private APIs. Now you can argue these restrictions are unreasonable but many of us don’t want our iPads or iPhones to be like our computers.

Sure, it's not arbitrary, but you didn't nail the actual reason: to make money.

If Apple was actually concerned about circumventing the App Store review process for the purposes of security, they would implement OS-level sandboxing and security models (e.g. something capability-like) - this is both far more secure and allows for more freedom to make apps.

But they don't, because it's not about security - it's about profit.

Re: Temptation of the Apple: Dolphin on macOS M1

#233

Post by povik »

fouric wrote: post #232
threeseed wrote: post #32

Earlier quoted context omitted.

Apple’s blanket ban on interpreted code is not arbitrary. It is there to prevent apps circumventing the review process and security model ie. apps pretending to do X during the review process and then doing Y when in use or obfuscating their use of private APIs. Now you can argue these restrictions are unreasonable but many of us don’t want our iPads or iPhones to be like our computers.

Sure, it's not arbitrary, but you didn't nail the actual reason: to make money. If Apple was actually concerned about circumventing the App Store review process for the purposes of security , they would implement OS-level sandboxing and security models (e.g. something capability-like) - this is both far more secure and allows for more freedom to make apps. But they don't, because it's not about security - it's about…

Don't they, really? I was under the impression that they do implement OS-level sandboxing and the ban on JIT/arbitrary execute is another level of security.

Re: Temptation of the Apple: Dolphin on macOS M1

#234

Post by fouric »

fauigerzigerk wrote: post #173
2OEH8eoCRo0 wrote: post #107

Earlier quoted context omitted.

>openness at the expense of security This is a false dilemma. You can have both.

I think you're right when it comes to security, but in order for that to work Apple would have to admit that checking apps for security issues is not inseparable from imposing rules that are supposed to benefit their own business model. That said, here's a challenge for everybody (including myself) who doesn't like Apple's app store monopoly and side-loading ban: Apple now requires apps to ask for permission before t…

> How would you prevent this from happening?

Very simply - enforce security permissions at the OS level, rather than the app store level.

There's no technical reason an app store also has to handle permissions. Leave the discoverability/reviews/curation functionality in the app store, and then just move the app installation functionality into the OS - the app store delivers an app package which the OS accepts, parses the manifest file, prompts user for permissions.

Put APIs behind a sane, capabilities-like model where the OS has to approve everything.

Facebook and Google can make their own app stores - but they still won't be able to spy on you by using privileged APIs without your consent.

(yes, they'll still be able to spy on you using data collection and aggregation - but then Apple's App Store privacy labels becomes a differentiating feature that build user trust and add value to the system, and Apple could add a warning when you install another App Store "privacy labels don't transfer, etc.")

Re: Temptation of the Apple: Dolphin on macOS M1

#235

Post by jchw »

pdpi wrote: post #16
dougmwne wrote: post #13

Wow, that frames per watt graph is an eye opener for sure. What an incredible advancement in mobile computing.

It's a petty thing, but that chart annoys me to no end. The numerator is FPS, not frames, so frames / watt should've been labeled frames / joule (or, well, FPS / watt, but that's nowhere near as fun).

The frames / joule suggestion is pretty funny. I forwarded along your comment and it appears to be fixed now, though.

Re: Temptation of the Apple: Dolphin on macOS M1

#236

Post by daveidol »

gjsman-1000 wrote: post #116
2OEH8eoCRo0 wrote: post #107

Earlier quoted context omitted.

>openness at the expense of security This is a false dilemma. You can have both.

This is an opinion, and Apple does not believe this opinion, nor do they have to. Furthermore, I think that if you look at the comparison of malware prevalence on Android and iOS, the claim that you can have security and openness simultaneously does not appear to be true.

> Apple does not believe this opinion, nor do they have to

Hopefully if they lose this case (due to the market reality of being a duopoly) then they will be forced to at least entertain it.

Android's way of handling sideloading or multiple app stores is far from the only way to do it. I'm sure Apple could find a better middle ground between what we have now (incredibly locked down, anti-competitive, with arbitrary rules and Mafia-like enforcement of prices) and a total free-for-all.

Re: Temptation of the Apple: Dolphin on macOS M1

#237

Post by robenkleene »

sillysaurusx wrote: post #202
threeseed wrote: post #32

Earlier quoted context omitted.

Apple’s blanket ban on interpreted code is not arbitrary. It is there to prevent apps circumventing the review process and security model ie. apps pretending to do X during the review process and then doing Y when in use or obfuscating their use of private APIs. Now you can argue these restrictions are unreasonable but many of us don’t want our iPads or iPhones to be like our computers.

I'm surprised to see no one has pointed out you're mistaken. This hasn't been true in quite some time. You can run whatever code you want. Doesn't matter whether it has a JIT, or whether it loads all its code from a webserver dynamically, or anything else. The sole criteria is "thou shalt not circumvent the app store review process." That means, do not change the functionality after they've reviewed it.

Here’s the relevant rule (https://developer.apple.com/app-store/review/guidelines/#2.5...):

> Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.

I’d say the post you were replying to uses the wrong word (“interpreted”, I usually say it can't run "arbitrary" code), but the rule is more specific than your description as well.

Re: Temptation of the Apple: Dolphin on macOS M1

#238

Post by kllrnohj »

Synaesthesia wrote: post #166
ninjinxo wrote: post #67

Earlier quoted context omitted.

Whilst very impressive, it's a bit exaggerated, they should have been locked to the same framerate for comparison: * 9900k is boosting to 5ghz which is sacrificing efficiency. * 9900k PC is delivering a much higher framerate, so it'd also have much higher GPU utilisation. * Afaik RTX3090 will have high power draw even at low utilisation (large card, lots of memory). From anandtech: >Should users be interested, in our…

Well that actually shows how impressive the M1 is because it hits faster CPU than the 9900k at 5ghz using only 10W-20W total. And GPU it's much faster than the Intel integrated.

Except it didn't. The 9900K was in a completely different performance category from the M1 in these dolphin tests.

To compare efficiency you need to control for performance. What Dolphin did here would be like trying to compare CPU coolers without controlling for power consumption.

What makes the M1 impressive is its performance relative to other CPUs in its power category (eg, the M1 vs. the i7-1185G7 in this chart: https://images.anandtech.com/graphs/graph16680/117493.png ), or when it manages to be both faster and use less power. That's impressive.

But using less power while also being significantly slower (which is what Dolphin's comparison is saying)? That's... not impressive or interesting. That's some "no shit sherlock" level stuff - just compare literally any mobile CPU from Intel or AMD vs. the desktop equivalent in the same generation. You'll see a chart that looks basically the same, with the mobile CPU many times more power efficient while also being a lot slower. Especially when you're taking the top-end desktop CPU for the comparison, the CPU where power efficiency isn't even remotely a design goal.

Re: Temptation of the Apple: Dolphin on macOS M1

#239

Post by mumblemumble »

_ea1k wrote: post #212
mumblemumble wrote: post #131

Earlier quoted context omitted.

It's probably better to think of that as AT&T trying to continue the thing they were already doing with feature phones, than as Google trying to make Android as locked down as iOS is. For starters, it's something AT&T did with just the phones they were selling, not something Google did with the Android platform or Android phone makers like LG and Samsung did with their phones.

True, and more specifically it was AT&T making their early Android phones into Android iPhones. This was still pretty close to the era when the iPhone was an AT&T exclusive. It was terrible and I believe they sold pretty poorly. My point is that the mumblemumble seemed to think that Google had no choice in the matter. I think they clearly did and for the most part clearly opted to keep the third party door open at th…

My point wasn't exactly that they had no choice, so much as it was a choice they quite understandably weren't going to make.

The AT&T analogy is kind of weak here because they weren't operating in the same business environment. AT&T was doing it in a B2C context, Google's Android business at the time was 100% B2B. It's easier to take this kind of risk as a major telecom operating in a B2C context, because consumers, as a body, aren't going to punish you that badly. Case in point was that, while these Android phones sold poorly, it hasn't actually tanked AT&T's business.

Whereas, if Google had sent Samsung, LG, Huawei, etc over to WebOS or wherever, the impact to Google's Android business would have been large and permanent.

Re: Temptation of the Apple: Dolphin on macOS M1

#240

Post by radicaldreamer »

r00fus wrote: post #227
Wowfunhappy wrote: post #215

Earlier quoted context omitted.

The apps you install expire after a week. You need to reconnect your device to a computer at least once every seven days and reinstall the custom app. Also, you're limited to three apps at a time. It's not actually usable for anything. It's also a completely arbitrary and needlessly-punitive restriction—if I've opted in to installing custom software, why limit me to three apps at a time, and why make them only last a…

Facebook has in the past asked users to deploy their Onavo app using this mechanism for their privacy invading VPN (2015-ish).

I thought they used an enterprise certificate? Those are still available and easily can be used to distribute software without Apple review (but perhaps not for companies as high-profile as Facebook)
Post reply on HN