Live data from Hacker News

QEMU for iOS

github.com

91–100 of 150 posts

Re: QEMU for iOS

#91
post #85

Earlier quoted context omitted.

This hasn’t been approved by Apple.

but it says "No jailbreak required!"... I thought that meant only appstore apps where allowed on your device...

You can sign and deploy apps to your own device with Xcode. This is all explained immediately after the “no jailbreak required” dot point in the README.

Re: QEMU for iOS

#92

Earlier quoted context omitted.

I said it was a 'usermode Linux "terminal" emulator', never said it was a VM or anything like that. IIRC the dev said he also wasn't allowed to publish it to the App Store and I assume it falls under the same catagory of "not allowed" in Apple's eyes as UTM would've had.

> I said it was a 'usermode Linux "terminal" emulator', never said it was a VM or anything like that. It's a full x86 emulator. > IIRC the dev said he also wasn't allowed to publish it to the App Store He didn't, it's just never been tested whether it could be on the store or not.

Actually, someone compiled it, added ads, and put it on the App Store. Not sure if it is still there, but it got through approval.

Re: QEMU for iOS

#93

> "Since iOS 13.3.1, it appears Apple has stopped allowing free developer profiles to sign dylibs." A terrible decision. Users should always be allowed, at the very least, to build and sideload their own code .

Many people still seem to believe that when they buy a phone (be it Apple or Android) they actually "own" the device. You don't really: . can't open it to access h/w, change battery, etc... . can't choose what you run on it . can't actually access all of the data that's stored on it . most of the things you do with it are recorded by a remote entity. . "for your own protection", here's a very long list of things we w…

I can't fully agree with your first point:

> can't open it to access h/w, change battery, etc...

We're necessarily moving closer and closer to monolithic ASICs that cover all functions of a phone, most likely encased in epoxy for complete waterproofing. Some guy with a screwdriver and multimeter will never be able to keep up with advancements in manufacturing/technology.

Re: QEMU for iOS

#95
post #93

Earlier quoted context omitted.

Many people still seem to believe that when they buy a phone (be it Apple or Android) they actually "own" the device. You don't really: . can't open it to access h/w, change battery, etc... . can't choose what you run on it . can't actually access all of the data that's stored on it . most of the things you do with it are recorded by a remote entity. . "for your own protection", here's a very long list of things we w…

I can't fully agree with your first point: > can't open it to access h/w, change battery, etc... We're necessarily moving closer and closer to monolithic ASICs that cover all functions of a phone, most likely encased in epoxy for complete waterproofing. Some guy with a screwdriver and multimeter will never be able to keep up with advancements in manufacturing/technology.

Silicon is one thing, but the comment you’re replying to specifically mentioned batteries. Non-replaceable batteries offer a modest reduction in size, at the cost of reducing the device’s service life to 3-5 years. I personally don’t find that to be an impressive advancement in technology. The design’s lack of respect for user-serviceability reinforces the other user-hostile features of the iOS ecosystem identified by the grandparent. (Sent from my iPad.)

Re: QEMU for iOS

#96

Earlier quoted context omitted.

> I said it was a 'usermode Linux "terminal" emulator', never said it was a VM or anything like that. It's a full x86 emulator. > IIRC the dev said he also wasn't allowed to publish it to the App Store He didn't, it's just never been tested whether it could be on the store or not.

Actually, someone compiled it, added ads, and put it on the App Store. Not sure if it is still there, but it got through approval.

Oh, that happens all the time. The real test is when the official app gets approved and stays on the App Store.

Re: QEMU for iOS

#97

Earlier quoted context omitted.

> Security This is arguable. The amount of CVEs is pretty high for a closed-source platform. Several of those CVEs were exploited in the wild for years before being fixed.

Unfortunately this is true for the other commonly-used mobile OS as well.

...which just lends more credence to the notion that you can pretend to be safe and lose your freedom, or you can face the reality that security isn't going to be perfect either way, and keep your freedom too.

Re: QEMU for iOS

#98
On Android, there is termux terminal emulator, which allows to run native Linux binaries and already has many packages. Arguably there were other ways also before termux existed: GNURoot Debian was an app that ran a minimal Debian chroot in fake root (`proot`), Before that there was KBox. In termux also I run a full Debian chroot using proot. None of this requires root.

Even without that, static binaries could run till some recent version. I have poked with dynamic loading and LD_PRELOAD to set up my own environment which could run most Debian packages using libfakechroot && libfakeroot.

People like to shit on Android. But in terms of power user freedom, apple doesn't even come near.

Re: QEMU for iOS

#99

Earlier quoted context omitted.

Why would you think that? Apple's processors are very powerful.

Emulation is slow.

Emulation is slow because it is emulating a CISC processor with a RISC processor. You are better off running QEMU on your Mac than on your iPad.

Does to hard drive limitations in space might not be able to run Windows 10 on an iPad or Macbook Pro.

Re: QEMU for iOS

#100

Earlier quoted context omitted.

Emulation is slow.

Emulation is slow because it is emulating a CISC processor with a RISC processor. You are better off running QEMU on your Mac than on your iPad. Does to hard drive limitations in space might not be able to run Windows 10 on an iPad or Macbook Pro.

> Emulation is slow because it is emulating a CISC processor with a RISC processor.

It’s slow because it’s emulating, period. CISC/RISC has little to do with it.

Post reply on HN