iOS on QEMU(github.com) |
iOS on QEMU(github.com) |
Zig are also working on it: https://zig.news/monthly/zig-monthly-august-2021-ios-support...
The pioneer of software dictatorship will probably make this impossible or illegal as soon as it gains any traction though. And people will probably congratulate them for it in the name of "security".
What does Microsoft have to do with this?
Consoles were doing that shit way before, unless you redefine what counts as “software” or “dictatorship”
In the case of the poster you are replying to. Yes, Swift is open source and there are compilers for other platforms. The problem comes in with Apple's SDK and their proprietary libraries. Those are what are required to build an app that'll run on an iOS device. Those only run on macOS/OSX.
Latest blog post: https://alephsecurity.com/2020/07/19/xnu-qemu-kvm/
So is the main use-case to find bugs in iOS or are there other major use-cases I'm not thinking about?
The only other use case I can think of is setting up a click-farm, or paid-review farm where you give positive reviews for apps for a small fee.
> No devices emulation: screen, touch, wifi, BT or anything else.
Is this possible as it stands? At least in bits and pieces I can put together?
Especially on an M1, perhaps running the arm builds wouldn't have too much overhead either, even though there are x86-64 images available as well.
Why isn't it _actually_ a fork though? I don't like when projects do this and don't actually make it a fork.
From Wikipedia:
In software development, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct and separate piece of software.
This seems exactly what happened here.
Are you asking why they didn't use Github's "fork" mechanism?
Github's "fork" mechanism creates a relationship between the two repositories that the developers of this software may not want. For example if the "upstream" ever becomes unavailable, all Github "forks" are auto-deleted. This is surprising to some people and definitely not what an independent separate development would want.
Bit weird/worrying as a user or whatever looking for the repo on Github between deletion and push, but probably not a big deal in the grand scheme of things?
The GitHub UI's concept of a "fork" is unrelated to Git. GitHub doesn't detect you made a proper fork if you don't use its API or UI to do so, and requires contacting customer support to change it.
Not worth the hazzle as it provides no benefit.
It was an interesting read because Linus has repeatedly dismissed github for kernel development, and he never explains why in detail (as a consequence most news reporting his soundbites are not very informative either)
It is a true fork though, both projects have the same commit history.
Really, though, I don't have a good reason why I think it might be ok to lock down a purpose-built game machine. So maybe that's just not ok either.
Speculation: I would be surprised if there isn’t a team internally working on a stripped down variant of macOS (or just Darwin + drivers?) designed for deployment as a server so that they can drop a bunch of racks of Mac Minis (or, with budget, some kind of blade arrangement with a Apple Silicon chip on it) into a datacenter and build a huge build farm (using VMs to run iOS and macOS, or jails if they ever get some kind of container setup). It would be dramatically better than having to manage x86 and all that extra bloat of average servers once you got through the growing pains. And they could guarantee security way better.
The next will be the gpu market.
No need to do the extreme just the one that can handle normal server load, flight simulator, even just 2k AA game.
Someone is doing the market analysis (not selling but real market segment under analysis), really what market one can hold the trillion dollar company.
I am not sure they can do Apple car which is mainly about hydrogen or electron capacity. But server and game …
Apple went out of its way to deliberately disable physical phones connecting to a virtual MacOS. Any other USB device can be connected, but not an iphone.
It works quite well for me. Simulator works fine (though graphics are slow) and so does connecting a physical phone (by passing through the USB controller).
(yes, I'm aware of a bunch of fragile solutions involving VirtualBox, but they tend to be slowish, that's also supposed to be paid if you're using the extensions for commercial operation IIRC, and several versions of macOS/OSX remain a huge pain in the ass to set up on it regardless)
its however not permissable, as you cannot buy apple software without agreeing to their licence, which disallows running it on anything but apple hardware.
for private fun projects: possible
for professional things: a very bad idea
Apple is not a software company, it's an electronic appliance company, like Samsung.
Of course, apple won't go after individuals who violate this provision. But is a cloud vendor or a CI vendor tried to pull that off, Apple would smash them.
[1] https://blogs.vmware.com/workstation/2020/05/vmware-workstat...
The only concern is the terms of the EULA so that's why the earlier poster says "for casual development"
There are a lot of guides online, including "one command" shell/powershell scripts that will automatically pull down the right files for you, and use the vmware/virtualbox api to create the vm automatically, and patch the bootloader to get Catalina or Big Sur loading, etc - if past experience is any indication, people probably already have Monterey beta loading fine already.
again, it's not a matter of "how" it's whether you (or Apple lawyers) care about the EULA.
In general, there's a pretty good second hand market for macminis, and if you shop around you can probably get something usable for under $350 shipped.
https://www.youtube.com/watch?v=juCz2ZzNOAY
Believe me now is so damn easy that it's funny. Now you have a lot of tools to load kexts and configurations. In the old days we loaded kexts manually:)
I built an 11th-gen Rocket Lake 128GB Hackintosh with Thunderbolt Display support+2 LED Cinema Display recently and it's been great. Thunderbolt 3 support on a Hackintosh has been nice. Just hoping for Thunderbolt 4/Maple Ridge drivers/11th-gen iGPU drivers if ever.
The question whether or not a EULA is enforcable is only relevant for products you bought which have software preinstalled - it is often argued under First Sale (and similar) that the EULA isn't applicable.