Hacker News new | comments | ask | show | jobs | submit login
Linux apps running on iOS via userspace x86 emulation and syscall translation (ish.app)
294 points by United857 70 days ago | hide | past | web | favorite | 139 comments



Looks like you have to compile it yourself (meaning you need a mac with Xcode) or install it through testflight. Although I'm surprised that it's even allowed on testflight. iOS doesn't allow you to execute code of any kind locally, which is why if you download a "learn python" app or something it has to send your code off to a server, execute it, and then send you back the result.

It's part of the reason why I recently moved away from iOS. Things like this are not supposed to exist, and you have to bend over backwards to make it work.

EDIT: Okay apparently this changed as of last year-ish? Looks like they have an exception in place for "a programming environment intended for use in learning how to program"* Regardless I think this kind of shell environment is still against the app store guidelines.

*https://www.theregister.co.uk/2017/06/07/apple_relaxes_devel...


Since last year Apple have allowed executing user-input code providing the application is designed for teaching programming, https://twitter.com/palmin/status/871980560943636480 has a summary. I can't link to the actual doc since that's behind a login.

I'm not sure how this app would be allowed though.


Pythonista has been on the App Store for 6 years. The first programming environment on the iPad I ever used was Codea which is based on Lua which was released in 2011, but there are many more. Genuine programming environments directly hosted on iOS have been around for a long time.

The main restriction in the past was on apps that downloaded code to run. For Pythonista and Codea and such this meant you had to either type in or cut-and-past in your code. However Pythonista has had the ability for you to write or paste in a dropbox sync script or FTP server script, etc, for may years, they just couldn't include it as standard. Since then this has been eased up so Pythonista now has a built-in feature to sync scripts to iCloud.


You can get a lot past the TestFlight review, which seems to be automated now. Probably just checks for API abuse and whatnot.

Getting to App Store is a human review.


I make the argument that this application downloads and emulates code that is user-editable in the form of x86 binaries, which is the same as Pythonista or similar downloading and running Python code.


I would think Apple themselves are looking into this (probably on the processor level as they control that now) for iOS; in order to make it more free for devs / users while having software run securely sandboxed, they need a way of running 'anything' securely. So I don't think they mind users testing out different ways of making it work and learn from it.

Does that processor have hardware support for it already but Apple just doesn't do software support? So they can only use it themselves?


Sorry, I don't quite understand your question. Are you asking whether Apple has put support in their processors for running arbitrary code inside a sandbox?


They are asking if the A series Apple chips have virtualisation features like Intel VT-x


I think they do, at least recent ones should. I don't think Apple has explicitly documented this anywhere, but I recall reading something like this recently.


I like that argument. I wonder if Apple will.


Well, it's on TestFlight already, so it's already passed one round of Apple's screening.


TestFlight builds to my knowledge only have to pass the automated scan. As such, as long as the dev isn’t using private APIs or doing other forbidden things that can be statically scanned for, it’ll get past that point.


I don't think that was a very deep look at the app, especially since you have to know how to use a Linux prompt to understand that this app is an emulator.


> I don't think that was a very deep look at the app

I doubt it was, but my headcanon is that some poor App Store reviewer saw something that looked like code and grabbed a supervisor to do a deeper review.


I haven’t heard the term headcanon before.

https://www.urbandictionary.com/define.php?term=Headcanon

An idea, belief, or aspect of a story that is not mentioned in the media itself, but is accepted by either the media consumer themselves or the fandom in general. If it is confirmed by the creator of the story, it becomes canon.


It's a quite popular term, but only within media fandoms. So if you don't fancy searching for clues in each single frame of a new episode of $TV_SHOW and arguing with strangers on the internet about how to interpret the exact wording in that dialogue, you probably haven't come across it yet.


That's a pretty arbitrary exception especially when Apple wants us to believe that iPads have made "computers" obsolete.


Not only can you run python on your iPhone, natively, with Pythonista, but you can call python scripts in Pythonista via Siri Shortcuts.


“Siri deploy heroku”?


Siri Shortcuts can natively run SSH commands now, so that is actually a real possibility.


Sure, if you set it up that way!


> iOS doesn't allow you to execute code of any kind locally

Yes, it does. And as of recently you can even put apps like this on the App Store!


it took a decade to "be allowed" and is still extremely rudimentary, not to mention its a very fine line to the point that mozilla and google still wont invest in a browser engine port because apple already told in the past that simply running JS in the browser is enough to breach their policy. so please stop shouting like its common place.

pythonista3 is a very controlled experiment as it is now. and it exploits a "tiny blessing" apple gave on the policy of running "user inputed source code" only!


> mozilla and google still wont invest in a browser engine port

The reason they won't do this is because they would't be able to JIT execute in their App Store app, which would make their browser seem unbearably slow.


While you're right that JIT isn't allowed on App Store, the issue with browser is you can only use built-in Safari webview for rendering websites. So all browsers on the App Store is a shell for Safari webview


My argument stands even if the "you must use WebKit" guideline is dropped. There's no point in writing a browser without WebKit because you just can't get good performance out of it.


This isn't true either. https://github.com/jcs/endless


The Github page says it's a wrapper around UIWebView, so it's still a form of WebKit provided by iOS.


Please don't spread misinformation, there have been very usable and capable dev environments available on the iPad since soon after it came out and their capabilities and access to features has been expanding steadily.

Codea (a Lua programming environemnt) has been on the App Store since 2011 and has had games written in it on the App Store since soon after as well*. Pythonista has been around for 6 years, has a built-in GUI designer, you can get Dropbox and Github syncing scripts for it and now it has a built-in feature so you can even sync your scripts between devices using iCloud. It also has apps written with it on the App Store.


> there have been very usable and capable dev environments available on the iPad

Usable and capable compared to what?

There is some stuff but it is always way inferior to anything on comparable platforms. That isn't obvious for MacOS, but certainly for iOS. Not that I am a huge fan of Android. It has a lot of similar problems.

But I cannot understand enthusiasm for Apple while it restricts access to almost any part of their software environment.


>Usable and capable compared to what?

Compared to pretty much anything - honestly. Pythonista is the gold standard. It has a fully feature integrated syntax highlighting editor, a built-in GUI form designer, graphics and media libraries for games, an integrated debugger, custom keyboard, a selection of Python third party modules such as scipy and Matplotlib, all the standard Python docs and tutorials and included module docs, full integration with share sheets, notifications, widgets, it's a universal app for iPhone and iPad, it integrates with the Github client apps such as Working Copy and it has built-in iCloud syncing for script folders. You can get Dropbox and Github Gist sync scripts pretty easily, I used to use an FTP server script a lot before iCloud integration came along. It's hard to imagine what else it could really need.

But let's compare it to the other major phone and tablet OS for a start. You even say so yourself. The dev apps for iOS are streets ahead of anything on Android. You seem to be arguing that in theory Apple's policies _should_ be holding iOS dev apps back compared to Android, but in reality that just isn't happening, even slightly.

I can certainly sympathise. About 6 or 7 years ago I was seriously considering getting an Android tablet because I expected the on-device dev story there to pull well ahead of iOS in the near future and wanted to be able to take advantage of that. What actually happened was I started using Codea, and when Pythonista came along I switched to that, and nothing comparable on Android ever materialised.

War story - I had to do a programming exercise for a job interview. I did most of it on my iPad on the train, including a custom compression exercise that involved writing my own bit-twiddling routines and a server remote control script using Paramiko, which of course Pythonista includes. I was remote controlling some Linux VMs running on my Mac in Virtualbox, using ssh from Python scripts directly from my iPhone!

It's a terrible shame and I don't understand why Android is so far behind on this. I suspect it's because the Open Source and Free Software communities have never really embraced Android and spent the time and effort to tool it up. Meanwhile Apple has been paying very close attention to this area and judiciously relaxing their rules in consultation with dev app authors. Whatever the reasons though, if you want to write scripts locally on a phone or tablet, iOS is clearly the way to go right now and that doesn't look like it's going to change any time soon.


> Compared to pretty much anything - honestly

I don't even have to try hard. I use a linux shell on a blackberry android phone (over 6in screen, so i call it a tablet), with a real keyboard, and it is years ahead of anything you describe.


In what way? I’d love to know, I can do a ton from Python but if the dev story on Android is significantly better I’m definitely interested.


I personally can't believe why Apple is still so popular in a place called "Hacker News".


Hardware hacker here, I can give you a few reasons. iPhones are designed to "just work" which is what I want in my main communications device. Sure, I could take one of the half-dozen SBCs on my work bench and turn it into a working cellphone with some parts and some sketchy code and a prayer or two, but I wouldn't want to rely on it daily.

As for my computer, I use a Mac mini that dual boots macOS and Linux. I have an older Mac mini that runs OpenBSD exclusively. I also have a media server I cobbled together from scavenged x86 parts.

I'm not a programmer, but it's my understanding from this community and others I frequent that Macs make for a comfortable and useful platform for their work and leisure computing life.

So, despite your attempt at gatekeeping, Apple products do have a place in a random hacker's workflow if that hacker decides he wants it; it's not up to you to decide what someone else uses and enjoys.


Did everyone just forget about the recent security chip deployment by Apple that literally makes it so you can't boot Linux from the internal ssd?

I've sysadmin'd all OSs for many years, but I'm with GP: I see Apple as another Microsoft these days (especially given MSs dubious push into non Foss oss) Hell even their efi implementation is non standard, and I really think people should pay more attention to Richard Stallman...(paraphrasing)

"Apple puts the user in a prison. It is a beautiful prison though".

Now, that's not to be defending others that do the same but in a different way (android is crap due to unrootable devices)...

Once again, the four freedoms as explained by RMS are the crux of the matter. The man was and is right, and it gets tiring seeing so many people bandwagon onto attacks against his person without addressing his position, for which I will always consider him a man who saw the future far before anyone else, and is getting more and more relevant every day.


> Did everyone just forget about the recent security chip deployment by Apple that literally makes it so you can't boot Linux from the internal ssd?

This is a mischaracterizsation. You can boot Linux, it is up to Linux to have driver support for the T2 SSD controller so that it can detect it as storage.


The default setting is to only allow booting from your current macOS installation or from another macOS installation that is signed by apple and currently trusted (requires an internet connection to verify).

That can be turned down to either accept any OS that was ever signed by Apple, or to boot whatever you want it to.

The third option should let you attempt to boot Linux, but like you said, whether the driver support exists is another matter entirely.


    Startup Security Utility -> Secure Boot -> No Security
https://support.apple.com/en-us/HT208198


Booting != installing


Certainly, anyone may choose the hardware they like.

But there is a danger in this type of "democracy", namely that we're heading for a future where true general purpose computing starts to disappear, and universities and computing enthousiasts have to pay thousands of dollars for a universally programmable computer. With Apple aggressively vertically integrating their supply-chain, and others copying Apple's business tactics, the writing is on the wall ...


>a future where true general purpose computing starts to disappear

I think just the opposite happened. All we had were general purpose computers, then we added "easy to use" computers in the form of smartphones and tablets. It just allowed a lot more people to take advantage of computers, it did not remove access to general purpose computers for the rest of us. Personally, I love the idea of a bifurcated world where the less technically savvy use devices that are far more restricted and secure. I really like that my parents can get a device, like an iPad, that does everything they need from a computer (email, facebook, light web browsing) without having to worry about malware.


Not at all. If anything, the more companies like Microsoft and Apple push for locked down systems, the more open source SBCs and hobbyist computers we'll see. There will always be a market for open computers, and the past few years have seen an explosion in that market.


I find this project to be pretty interesting, don't you? I think this makes it meet the bar for the guidelines.


Comment is about Apple, not about the project.

I can already run Linux on my desktop computer, and I intend to buy a Librem phone when it comes out, so I can run Linux without performance penalties on my phone

... and without possible retraction by Apple looming over my head.


> mozilla and google still wont invest in a browser engine port

Gecko runs just fine on iOS.


Wait, this is news to me. I was under the (probably erroneous) assumption that Firefox on iOS was running under webkit. Am I wrong?


Firefox for iOS is built on WebKit.

Gecko runs just fine on iOS; it just isn't deployed.


Took a few Google search iterations but I found this: https://hg.mozilla.org/users/tmielczarek_mozilla.com/gecko-i...

That's neat. Looks like the last commit was in 2015.

Is there any backstory to this project? Was it just research? Is it abandoned?


Looks like it was abandoned. One of the last commits was “Disable the JIT on iOS because it’s busted”.


Uh. There’s definitely a local python interpreter on the App Store. Pythonista3 is one, and Blink has one as well iirc.


Yes, and python isn't JIT'ed, so it really doesn't matter. It all boils down to write XOR exec memory.


I'd imagine that the majority of people who want to run a terminal on iOS would have access to a Mac and Xcode, so even if this can't be released on the App Store, it could still be a useful project for many.


You would also need a paid developer account if you didn't want to constantly resign the app.


Opening Xcode once per week and pressing CMD+R is likely not a big problem for the target audience either.


> I think this kind of shell environment is still against the app store guidelines

How so? I see no guidelines this app is violating.


Apple Developer Program License Agreement:

3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded.

3.3.3 Without Apple’s prior written approval or as permitted under Section 3.3.23 (In-App Purchase API), an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store or VPP/B2B Program Site.

App Store Review Guideline

2.5.2 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.


All the scripts, code, and interpreters are packaged in the app bundle, since it's emulating x86 binaries. The "additional functionality" guideline is a bit loose because companies download patches (for A/B testing, bug fixes) all the time, which doesn't go through App Store review.


"All the scripts, code, and interpreters" are not, in fact, packaged with the app as you are able to download arbitrary binaries using curl/wget or apk. That clause is very clear in both wording and intention, and this application does not follow it.

As for the A/B testing that some companies do via sketchy runtime hooking, that has been a boundary case for a while that sometimes does cause you problems with Apple, but was vaguely OK if and only if the downloaded functionality was run through JavaScriptCore: the old version of this restriction essentially used to say "only if run in WebKit" (and I got manual clarification once that they were OK with JavaScriptCore, though I think they also made that explicit in the rules at some point).


> "All the scripts, code, and interpreters" are not, in fact, packaged with the app as you are able to download arbitrary binaries using curl/wget or apk.

I'm making a distinction between the code that's downloaded and interpreted and the actual app's code, which is important because I can download a FRACTRAN (or your favorite Turing-complete language) interpreter written in Python and run it in Pythonista and run afoul of this rule unless you take the interpretation of "scripts, code, and interpreters" being the ARM code that is running natively on the device that implements the emulation system. So if you look at the "arbitrary binaries" (which just so happen to less readable, non ASCII "source code" for iSH) being equivalent to Python scripts, there really is no issue here. No native code is being downloaded, generated, or executed in either case.


You are making a distinction that this clause went far out of its way to keep you from making :/. When Apple says "scripts" and "code" they are absolutely and clearly talking about the code that is being interpeted, not the interpreter itself (which they call "interpreters").

Pythonista, which is "borderline", might actually be possible to claim is an educational app: the person who wrote it seems to discuss it like that, and that is often how it is used. Apple seems to want to allow apps that are able to be used for teaching people to program. That is not the stated purpose of iSH nor is it how most people seem to want to use iSH.

You just really really seem to want to believe that this is OK based on this clause, but you are past the point of "stretching" and are now just seemingly purposefully refusing to understand Apple's restriction and also seem to not understand that this isn't some black and white "letter of the law" sort of thing but a massive grey area of "what is Apple's intention here" (which includes wanting to avoid creating a little app ecosystem inside of another app, which the binary package manager here clearly does).


> When Apple says "scripts" and "code" they are absolutely and clearly talking about the code that is being interpeted, not the interpreter itself (which they call "interpreters").

They can't be, because all of these are lumped together in the category of "must be bundled with the app".

> Apple seems to want to allow apps that are able to be used for teaching people to program. That is not the stated purpose of iSH nor is it how most people seem to want to use iSH.

I mean, you could repackage this as "learn the Almquist shell".

> You just really really seem to want to believe that this is OK based on this clause

Because that lets it be on the App Store!

> you are past the point of "stretching" and are now just seemingly purposefully refusing to understand Apple's restriction and also seem to not understand that this isn't some black and white "letter of the law" sort of thing but a massive grey area of "what is Apple's intention here" (which includes wanting to avoid creating a little app ecosystem inside of another app, which the binary package manager here clearly does).

I think we both understand Apple's restriction on alternative App Store environments, and I agree with you that the software as it currently stands will likely never pass actual App Store review with apk bundled with it. But I still think it's possible for it to be approved provided it shipped without it, even if getting a package manager onto it would be possible because it it exposes the filesystem through iTunes file sharing, as well as allows for downloading one. As you've mentioned, this is really about perception: if Apple thinks you're trying to make an "App Store" inside your app, they'll quickly shut it down, but if you make it annoying but possible to do something like this in-app they might buy the argument that it wasn't your primary intention.


> They can't be, because all of these are lumped together in the category of "must be bundled with the app".

...that's the point: they are explicitly saying that both the interpreter and the code being interpreted must be shipped with the app, as that clause is directly saying you can only have an interpreter if there is no scripts or code being downloaded to later run on said interpreter.

> I mean, you could repackage this as "learn the Almquist shell".

...but they didn't. This same argument is the argument "in some theoretical alternative reality my BitTorrent client is mostly used to download files that can be legally redistributed, so the fact that even I am not using it in this way should not be counted against it"... but it isn't.

> > You just really really seem to want to believe that this is OK based on this clause...

> Because that lets it be on the App Store!

Whether this is to be allowed in the App Store has very little to do with what Saagar has chosen to believe, particularly if that choice has been made out of convenience.


Why run x86 Linux binaries? Wouldn’t it be easier and more efficient to run ARM binaries? Then you’d only need syscall translation, no? I guess you would also need a thuniking layer to handle binary format/ABI differences. But that would still be better in terms of time and space than emulation I would think.


See discussion from earlier today as to why this wouldn't really help: https://news.ycombinator.com/item?id=18425906


I'm still not convinced. Even something like early VMware that scanned for the gnarly pieces that break Popek&Goldberg but just passes through most instructions should be better. In this case probably just syscall, some crazy system register reads that might return different things (but there aren't many of those in AArch64 EL0), and enough thunks that code can pretend it's executing at it's original location. Hell, equally sized RISC instructions should mean you can more quickly scan code than VMWare had to put up with doing crazy CISC decode just find out if they need to translate an instruction or not.


You can't do the thing you are suggesting because that would require being able to take those instructions that are being "passed through" and run them, which would require marking them executable. What you would effectively end up having to do is write an emulator for ARM, at which point you haven't gained anything. Choosing x86 was a really sane choice given how many existing tools and packages are available for x86 (though ARM is, of course, becoming more popular and accessible).


>because that would require being able to take those instructions that are being "passed through" and run them

Isn't this just a matter of writing it to some page and then setting the RX bit?


The ability to mark a page executable would defeat Apple's codesign feature, so a normal developer definitely can't do that.


It's basically the easiest way of treating data as instructions, sort of like executing a compiled program as you would with an interpreted language?


> Isn't this just a matter of writing it to some page and then setting the RX bit?

Yes, but this is not easy to do on iOS: you need certain entitlements to perform this operation.


Likewise.

Obviously it's not as simple as in Android where you're already inside a Linux shell under the covers, but there's no technical requirement I've read here that should mandate emulation.

Aside from the above, the syscall layer alone would be much more useful than bundling emulation into the picture that we know is going to perform poorly.

An aarch64 Linux rootfs on the A12x would have me throwing my money at one right now.


> there's no technical requirement I've read here that should mandate emulation

I mean, what's wrong with the requirements that I mentioned? It's fundamentally impossible to run these binaries unaltered and still hook syscalls, which means that emulation is required.


You're confidence about this makes me not doubt that you're correct, but the linked thread doesn't really discuss this in enough detail that it's clear that running a native sandbox is not possible.

I'm not really experienced with iOS' underlying architecture, so I'll happily take your word for it - it's just that the linked thread mentions that virtualization is possible but not but sort of.


The fundamental argument is that you will need emulation at some point because every syscall needs to be hooked, so you need to be able to stop before a system call is executed and respond appropriately. If you are running native code, you'd need to change the binary at runtime to do something else instead of the syscall, which means you're essentially writing to executable memory.


The reason you need emulation is not to hook the syscall instructions, even if that is sort of in the same general area as true: it is because the code for these binaries is not shipped with the app and signed. If you were going to limit this app to the code that was shipped with the app you could also just replace the syscall instructions as part of the same pass that signed the binaries. Even if you didn't need to hook the syscall instructions, it is the lack of code signature on these files that is requiring the emulator.

You are coming to mostly correct conclusions here, but frankly all of your explanations for this are confusing and most of them are incorrect :(.


I maintain that I mostly understand what is going on here, but I'll concede the point that my explanations are confusing and/or not directly to-the-point. You're much better at explaining things than I am ;)

> if you didn't need to hook the syscall instructions, it is the lack of code signature on these files that is requiring the emulator

I had considered a very sketchy solution for this for a personal project (from the App Store's perspective) of what would be the equivalent of hacking the package manager to only install my packages which I sign beforehand with my certificate, which kinda allows installing arbitrary things to the extent of "what I have decided to compile and sign".

> The reason you need emulation is not to hook the syscall instructions, even if that is sort of in the same general area as true: it is because the code for these binaries is not shipped with the app and signed.

There are two "signing" issues here which really are the same but I've separated out because I felt it to be appropriate, though in reality the second shouldn't occur: one is loading unsigned, arbitrary code from say a package you just downloaded, and one is modifying the execution of the program to emulate syscalls. If you somehow got iOS to load and execute your unmodified unsigned ELF executable, then you'd have to emulate system calls in some way, which I suggested you could do by performing the modifications you'd normally perform before even signing the binary at runtime by manually patching syscalls in executable memory (which requires JIT).


So it's mainly an iOS limitation? I don't understand why it shouldn't be possible to take the same route software like WINE or WSL have taken before on a less constrained OS like macOS.


Yes, this is mostly an iOS limitation rather than a hardware one. There are many ways to make something like this work if iOS allowed things like forking processes or JIT (for App Store apps)–actually if this was possible, the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do.


> the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do.

Or jailbroken iOS for that matter (at least when I last did a jailbreak which was quite some years ago, I honestly don't know about the current situation)


I kind of miss being able to SSH into my iPhone and run scripts, or just poke around the filesystem. It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server. That was about 8 years ago.

I might do that again sometime. It's not urgent though, and I wouldn't switch to Android just for that. But I keep an eye on the jailbreak community.

I also really like the idea of having a portable keyboard and screen to turn my phone into a little development machine. I think the CPU is actually more powerful than my old 2012 MacBook, although it doesn't have as much RAM.


> It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server.

There’s a number of apps on the App Store already that allow exactly this. Two of my personal favorites are Blink and Termius (use them both, but for different reasons).


Oh yeah, thanks, I was looking at Blink earlier. Haha actually I don't really need it, so I didn't install it. It was more about the feeling of "hacking" my device and doing something that it wasn't supposed to do. And having a real shell with access to the iOS file system, where I could script the phone to do all kinds of things, and write little programs that could run on a cron schedule. Stuff like that. For example, I wrote a little script that would change my iOS wallpaper once every hour, and it would take the images from a Dropbox folder.


I wonder to what extend it's possible to include every executable from the standard apt-get ARM repository (but not any other resources) in the app. Since the code is included at compile time and bundled with the App, Apple should allow it. Then one could add some sort of apt-get shim that fetches the non-code resources and installs them; and something to catch system calls (which could maybe be overridden at compile time as well).


FWIW, without nitpicking your language (as it is clear what you are saying, and the question is a totally legitimate one), the answer is "yes: that would absolutely be possible".


Not if the resulting executable is on the order of tens of gigabytes in size, or if the executables use features that aren't available/allowed in iOS (like runtime code generation and execution).


This is Alpine Linux, so there's no apt-get ;)


"standard apt-get repository" is wrong in so many ways that I don't really know where to start correcting it.


To prove that it's easier to make binaries run in another OS altogether than in another Linux distribution. That would be my guess.


Docker does that (and so do LXC, Flatpak, Snap, etc).


There's been a sorta similar thing for Windows for almost fifteen years now, called CoLinux: https://en.wikipedia.org/wiki/Cooperative_Linux

It runs a Linux kernel on top of the Windows one, without processor emulation, so you could say it translates Linux calls and semantics to Windows' control of resources.

However, it didn't gain any significant use, and is apparently abandoned.


How different is that to what Microsoft is officially supporting via the Windows Subsystem for Linux?


WSL isn't Linux, it's an re-implementation of the Linux kernel syscall table, that translates them to the Windows equivalent. It allows userspace Linux programs to run on Windows.

It would be more accurate if they called it the Windows Subsystem for Linux Apps.

If you give a Linux program a complete syscall interface, it will run (provided it has its' libraries and a libc to work with).


This is a very nice effort but I can't help but dream of something like xhyve + alpine side loaded on an iPad Pro.

I just want to run neovim and use its terminal emulator and a few cli tools.


iOS doesn't have Hypervisor.framework like macOS does, unfortunately, which makes a project like this significantly more difficult. Hence the need for an emulation layer. However,

> I just want to run neovim and use its terminal emulator and a few cli tools.

This is doable with the project as it is currently.


Be that as it may, the lack of Hypervisor.framework just means there is no Apple sanctioned way to publish an app like VirtualBox in the App Store.

I'd still happily pay the yearly Apple developer tax to side load until Apple ends up shipping one when it transitions from x86 to ARM. ;)

AFAIC rolling your own hypervisor is technically feasible just would not be very performant.


Previous discussion at a link to the github repository: https://news.ycombinator.com/item?id=18421016


Why not build a simple aarch64 machine code runtime and skip the emulation by running aarch64 Linux ?


I've described why this doesn't work when this thread came up earlier today: https://news.ycombinator.com/item?id=18425906. In essence, you will need an emulation layer anyways, so it doesn't really matter whether you're running x86 or ARM.


I thought apple disallow apps like these?


They have disallowed similar apps, but I’ve made a case that this app in particular doesn’t violate any of Apple’s guidelines.


ish seem to work in macos as well...

There’s also this interesting project:

Noah is a Darwin subsystem for Linux, or "Bash on Ubuntu on Mac OS X". Noah is implemented as a hypervisor that traps linux system calls and translates them into Darwin's system calls. Noah also has an interpreter of ELF files so that binary executables of Linux run directly and flawlessly without any modifications.

https://github.com/linux-noah/noah

https://events.static.linuxfound.org/sites/events/files/slid...


It would be awesome if they let you type commonly used symbols with the swipe down feature like in Swift Playgrounds—then you would not have to go through multiple screens full of characters to get the angle bracket or curly braces.


On iPad, this keyboard comes by default for all apps (including iSH), since it’s provided by the system.


Swift Playgrounds changes the symbols that you can type with the keyboard in that mode. Normally, you can’t type curly braces or angle brackets on the first level of the iOS keyboard, but you can in Swift Playgrounds (and when entering LaTeX into Pages).

All I’m saying is that it would be nice if iSH customized the keyboard the same way.


Can't you run ARM binaries straight? No need to emulate the CPU. Same as Wine runs Windows programs without emulating it (as long as it's used on x86 arch).


You can, but not in the way you'd expect. Codesigning is a big issue, but one that can be circumvented if everything is signed in advance, though you probably wouldn't be able to publish to the App Store. But specifically for an app like this, you'd need an emulation layer: https://news.ycombinator.com/item?id=18425906


Or... you know... you could just get a Chromebook that has Android apps and Linux apps (via Crostini) in a supported fashion.


Does that mean I can install Steam and Proton and play (WindowS)-Linux games on iOS?


I doubt it. Alpine Linux would need to support Steam (which I don't think it does?) and then this project would need to implement all the syscalls to make this work, which hasn't quite been done yet. Plus it will be really slow.


This project happens to ship a userland from Alpine Linux, but it is not at all clear to me why it would be limited to run software from Alpine Linux.


By "Alpine Linux", I meant "the stuff that Alpine Linux usually ships with", which I doubt is rich enough to support everything that Steam needs, plus you're not going to get a nice package to install as you might on another distribution: https://developer.valvesoftware.com/wiki/Steam_under_Linux. So I'm pretty sure the answer to the original question is still "no, not yet", though I don't think it is "no, not ever".


You still don't seem to get it: this project happens to ship with an Alpine Linux userland, but you can just build it with Ubuntu Core instead, it will just be insanely large. Alternatively, you can just download Ubuntu Core and either replace the Alpine parts or put it in a chroot. Steam isn't going to run because it doesn't have a graphics layer, but it isn't because this is somehow--and I mean right now as it is installed on your phone without even having to reinstall it--in any way tied to Alpine Linux.


I do realize that this is using Alpine because it's small and easy to package, and that it's not in any way tied to Alpine. I wouldn't be surprised if you could do this on device right now by nuking the folder (which is helpfully exposed through Files) and unpacking a Debian filesystem into there. And I doubt any games will run at all, even if you do this, because emacs doesn't work currently due to missing system calls. My response was basically saying that along with "Alpine Linux likely doesn't support Steam, so if you download the app you won't be able to install it easily."


Alpine will have a growing catalogue of software for phone and tablet as the popularity of postmarketOS increases.


Something like this (the end result, anyway) can already be accomplished with Moonlight [1], if you have a Windows machine with Nvidia GPU.

[1] - https://moonlight-stream.com/


Apple does not permit you to do such things with their devices.


This is really cool, can anyone detail how the syscall translation works?


When a syscall occurs, handle_interrupt is called to translate the call into a system one: https://github.com/tbodt/ish/blob/master/kernel/calls.c#L135


It would be interesting to run it nativity as well, ARM compiled.


Someone just ported FreeBSD Linux Binary Compatibility layer to iOS? :)

https://www.freebsd.org/doc/handbook/linuxemu.html


i think a ssh client is enough.


SSH only works when you have a network connection.


You also need another computer, which kind of defeats the purpose. That's like saying you don't need wine when you have VNC.


You have something called loopback.


…which requires your device to listen to SSH connections, right? This isn't something your iPad is doing.


You would jailbreak your iThing and install ssh server.


If you're jailbroken, you can just spawn a shell. No need to do a SSH loopback dance.


This reminds me of Blink Shell, an iOS "shell" that primarily features ssh and mosh. It also implements a bunch of shell commands (a selection of coreutils and netutils), running natively, but with a shim for `system()'. The idea is that you get a shell environment with the same tools (or almost the same tools) as you would on a traditional *nix system.

I think it's a much more practical approach, especially given that Apple seems to be okay with it on their App Store. However, it does leave some things to be desired that'd be totally catered to by the iSH approach, assuming it develops into something much more complete (I tried the TestFlight and while a basic environment was present a lot of things that'd make for a useful environment didn't seem to be implemented).


> I tried the TestFlight and while a basic environment was present a lot of things that'd make for a useful environment didn't seem to be implemented.

Not that I disagree, but would you be willing to provide some insight into what you personally felt was missing?


Not GP, but most of the apps I tried to install and execute I got “Bad System Call” notices from (some going so far as to crash init too). I reported one of those apps to the developer and they indicated it’s fixed on master, but I’ve not had a chance to compile yet (and developer said the same about an updated TestFlight build). Vim was one of the few things that worked decently well, but without a Bluetooth keyboard for Esc it was a little painful. I really like this project so I intend to get builds up and going soon and will be filing much more detailed bug reports (and ideally PRs) soon.


I can see apple buying this!


Thanks to saagarjha for the effort and making the case to Apple that this should be fine. If it is allowed, it opens up a lot more possibilities.


> Thanks to saagarjha for the effort and making the case to Apple that this should be fine.

I haven't made any case to Apple…this is not my software.


Oh sorry, I assumed it was :) Well, nice feedback then anyway here on HN!


It seems like no one wants to run Linux or its applications lately and they seem happier when Microsoft develops Windows applications and operating system things to handle Linux things. Now Linux apps run on iOS and it's starting to sound like Linux people are happy to see their stuff built by others and running on everything but Linux.

Now, in this day of so much fake news, I wouldn't be surprised that all the happy comments I read are by Microsoft and, now, iOS shills but it's an observation I've made.


I think much of this is Microsoft and Apple attempting to retain marketshare. Niether has well maintained, vast software archives like Debian, or instant rollback after a package install or update like SUSE (thanks to btrfs and zypper).

Meanwhile the non-phone computer market is shrinking each year, and what remains is mostly a market for devices that are good at running browsers.


I am positive Microsoft does it for that reason but this isn't a project by Apple.


This is an awesome feat you have accomplished and just when I had given up on anything new & cool coming out of the crAPP Store. Thanks for your work.




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

Search: