iSH – A Linux shell on iOS
github.com
github.com
I’ll have to read more about iSH to learn if it’s a “true” shell, or effectively just emulated or with strict limitations, but either way the potential inspires of how great it would be to have a true shell and/or dev tools for iPads.
Oh and I did this on my iPhone X because I am still undecided on the new iPad. There doesn't seem to be any issue at all, despite the small fonts. The screen is actually large and hi-res enough that it's workable. I can have a NERDTree and a wide buffer with no wrapping, or 2 buffers side by side with a tiny bit of wrapping. Obviously an iPad would totally solve that.
I want this to work for a few different reasons.
1. Be able to do the occasional odd task or put out a fire on the go. On vacation probably, when I am not planning on doing work and leaving my laptop home.
2. Have a consistent development environment which I can reach from anywhere on any device, and pick up right where I left off. (So far tmux sessions have been an awesome lightweight solution for this)
3. Taking it a step further, perhaps leverage a server in the cloud which I can spin up/down as needed, and customized for low cost or stupid power.
4. Rely less on the mouse
5. Divorce myself from IntelliJ. While while awesome, is pricey and bloated, and abstracts away a lot of cool command line tricks behind the GUI.
So far my personal challenge is just getting used to vim + tmux. I've been using IntelliJ mostly for the last few years but have a bit of experience with vim and tmux to get started.
The next hurdle will probably be figuring out how to get a workflow set up that involves a browser loading the code. I expect lots of annoyances around outputting something on the remote machine which I then want to view on the iOS device, like an image or CSV. Working around the lack of a real local file system is going to be like pulling assets out of another dimension.
I was going to go the vim+tmux route, but I never got into tmux and I happened across Modern Vim by Drew Neil. The book describes how to use nvim's terminal emulator mode and the ability to save sessions. I am hoping this will allow me to just use nvim for coding instead of nvim+tmux.
I also intend to have a build flow that pipes it into a server for easy downloading and, if need be, uploading.
While I have the first gen iPadPro (works fine for this, of course), it did occur to me how amusing/stupid it is to think of using one of the most advanced consumer mobile devices as a dumb terminal like it was the 1970s.
Of course I still prefer giant monitors to fit a lot of different panes for inspection and debugging, but it's pretty serviceable.
https://www.amazon.com/Dell-Monitor-43-Multi-Client-P4317Q/d...
(I use this for work, and absolutely love it.)
For portable use though, I think an iPad could very well be superior to modern laptops. The hardware of Apple’s iPad Pro is certainly well beyond that of ultraportable laptops on the market now. The only missing piece is the software.
Or, on newer iPads, directly via the USB C connector. And apps can recognize that you have chosen to plug in a secondary display and suit their content to match on the other screen.
And hilariously enough, I think that would actually be within Apple's license, since an iPad is, after all, Apple branded Hardware.
Fedora/RISC-V is dangerously close to being useful; the only apps I miss are a couple of the big hurdles: Firefox, GHC, and Java.
I was under the impression that emulators were forbidden in the App store (?)
Or does it hold only for software running inside an emulator?
It's in fact "distributed" via TestFlight, legally speaking (and practically) it's not on the App Store.
https://www.quora.com/Why-does-Apple-hate-emulators-while-Go...
What I haven't seen mentioned yet is the fact that there is no way to run a browser/javascript debugger on ios. You can do it remotely, but not locally. This is the missing link for me in terms of using an ipad for serious dev work.
https://itunes.apple.com/us/app/inspect-browser/id1203594958...
Honestly? No, absolutely not. My rMBP is 13" and that's the smallest screen I want to program on.
I care about the tools I use to do the work I do and I don't want to compromise (or compromise very little). I don't think I can get serious work done on an iPad without faking it and saying, "um, sure, it's great!", and without honestly feeling claustrophobic.
So the reality is that there’s no such thing a no-compromise dev setup: Either you optimize for a desktop setup, or for portability, or somewhere in between. If you have the ability to have both a desktop and portable setup, such a pair I almost always going to be superior to just one medium sized laptop: Your desktop experience will be better with massive high resolution monitors, and your mobile experience will be better with a lighter, slimmer device and longer battery life etc.
Apple has recently added an exception to this rule if you’re willing to classify your app as an “educational” app, and allow for the viewing and editing of the source code you download. Since this shell allows for grabbing a copy of the source code of the packages you install, and compiling them yourself, I think it just barely falls within the rules:
> 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.
> is being distributed via Test Flight (which apparently has way more open terms of use than I would ever have expected)
There is no exemption for TestFlight apps; they should comply with the App Store Review Guidelines as usual:
> Any app submitted for beta distribution via TestFlight should be intended for public distribution and should comply with the App Review Guidelines.
Note that any builds that go through TestFlight are subject to a review process.
I mean: this is a great implementation of an emulator. I have downloaded and tried iSH, and it is actually "kind of epic". This isn't exactly what I thought it would be, glancing at the source code: it sounded like it would be running the Linux kernel (so actually be Linux) in console mode, but this is a library operating system and is very similar in many ways to the project I sometimes talk about (which also provided a library operating system, but was going to distribute pre-compiled code as part of the application to avoid needing an emulator), but this is clearly better as an emulator (and is much easier to do, despite this emulator being a slightly harder emulator to build than most).
So, this is a great implementation of this--this is even a "heroic" implementation of this--but, at the end of the day, this is the thing Apple was trying to stop (as much as I hate Apple for that).
Ok, let's widen our view of open source then. Pythonista lets you download Python code and then it interprets it, and iSH lets you download compiled x86 code and then interprets that. So it's still open source, see!
> I can use this to download SOCKS proxies (that despite not being VPNs I believe are still banned in the Chinese App Store, though I might be wrong about that: they are definitely illegal in China)
I'm not following you. How would iSH be able to actually apply these proxies system-wide unless it's a VPN app, which as far as I'm aware it's not? All it can do is possibly download VPN profiles, but I can do that in Safari too. Perhaps I'm misunderstanding how SOCKS works, but I don't see how this could change anything except traffic you're sending in-app at the most.
> I mean, this is literally "an emulator", which is a core example of a thing that Apple wants to not exist.
You're going to have to provide evidence for that–Apple used to do this by citing 2.5.2 in their App Store Review Guidelines, which explicitly forbid this kind of thing, but as I mentioned there is now an exception poked in it for "educational use". Has any "educational" (i.e. non-piracy) emulator recently been rejected by Apple, and if so, under what grounds?
> at the end of the day, this is the thing Apple was trying to stop
Again, I disagree that Apple would try to stop this, at least under the current set of rules that they have. The fact that it made it through TestFlight review is pretty telling, I think.
Only to the static analysis part, not to human review.
Maybe it isn't App Store compliant, but who cares?
I don't install my dev tools on the desktop via app stores either.
For all I care, someone could port Homebrew for iOS and force me to install it via Xcode.
This hasn’t been true for a long time.
No. There have been multiple efforts to do something like this before; I seem to recall one app on the App Store that attempted to simulate commands being run by parsing arguments and performing the correct actions as they were entered. Personally, I have an experimental shell that abuses cross-compiled Mach-O ARM64 shell binaries, but there are some limitations to this approach that I need to resolve regarding codesigning, App Store guidelines, and advanced shell features such as piping which are difficult to emulate in the single process that iOS gives you. I might get around to posting it online if I get the time.
Are there any plans to build some kind of connection between the filesystem here and the native ios filesystem-thingy? It would be delightful to be able to edit something in real vim and then save it to icloud...
For now, Nicolas Holzschuch's fork of iVim (https://github.com/holzschu/iVim) is still by far the best solution, but iSH definitely has the potential to take over.
If this software could be developed and installed, cross-compiling a native Unix toolchain, either from the open source code distributed by Apple, or the BSDs, or even GNU, should be just as easy to pull off.
So what gives?
That’s fine for most GUI-driven applications, but it’s kind of problematic for a traditional *nix-style shell. If you were Apple, or you had a jailbroken device and could circumvent the sandbox, you wouldn’t have any problems running a normal shell and command line utilities.
Which Apple has cleverly made sure are not under the control of your process. There really is no way to reliably spawn another process and get it to communicate back to your application.
> If you were Apple, or you had a jailbroken device and could circumvent the sandbox, you wouldn’t have any problems running a normal shell and command line utilities.
Apple does in fact have the ability to spawn a shell on internal devices.
It makes owning such a device even more baffling, sounds incredibly useless to me. I didn't know iOS was such a trash fire.
Can you run bash on your dishwasher?
But yes-- I certainly do expect to be able to run a shell on any computer that I own. It's nice to hear that iOS devices are just another appliance for the affluent majority.
Fun fact: the kernel has continuously been dropping features that are seen as “unnecessary” on iOS. For example, I recently heard that iOS no longer supports setuid at all; the entire feature has been ripped out of the kernel because it’s not used.
No way Apple will let you put that on the App Store though!
Extraordinary claims require proof.
I assume, based on the first comment in this chain - I'm not experienced with emulation of different processor architectures.
That would be quite feasible and not at all impossible. And given that the original author of this amazing project has the balls required to pull off a JIT-type scheme to do x86-ARM translations, quite probably within their reach.
Bingo. You need the get-task-allow entitlement (which Xcode will automatically inject in your debug builds, but will not allow you to submit to the App Store with), and have had ptrace called on you–either through the debugger, or if you ptrace yourself with PTRACE_TRACEME.
MacOS has a BSD user-land, the kernel isn't anything to do with BSD.
The kernel also includes code from BSD, source is available, including from FreeBSD/NetBSD and OpenBSD. For example, the network stack is BSD code. It also includes OpenBSD's pf(4).
For example, there was a recent ICMP vulnerability in XNU, that later affected FreeBSD. So please reconsider posting misinformation in the future.
Mach was not a modified BSD kernel, it was a research kernel developed at CMU developed from the Accent and Aleph kernel(s) as a replacement for the BSD kernel, nothing to do with BSD excepting that BSD took some ideas from it... later.
https://en.wikipedia.org/wiki/Mach_(kernel)
Look at the repo, the BSD sources are nothing but a userland (POSIX) API layer + the odd device compatibility layer.
Please refrain from posting misinformation in the future.
https://opensource.apple.com/source/xnu/xnu-4570.71.2/bsd/ne...
https://opensource.apple.com/source/xnu/xnu-4570.71.2/bsd/ne...
https://opensource.apple.com/source/xnu/xnu-4570.71.2/bsd/ne...
You will find RCS tags for OpenBSD/NetBSD/FreeBSD littered throughout the kernel source tree, some files even retaining original SCCS ids from 1980's CSRG days.
$ grep -R "\$OpenBSD:" | wc -l
24
$ grep -R "\$NetBSD:" | wc -l
138
$ grep -R "\$FreeBSD:" | wc -l
162
$ grep -R "\$KAME:" | wc -l
73
$ grep -R "WIDE Project" | wc -l
87
$ grep -R "The Regents" | wc -l
427
$ grep -R "Berkeley" | wc -l
919
Don't presume to know who you're talking smack to, when it's clear you have absolutely no idea what you're talking about.
its a "micro" kernel... its small!
I'm talking architecturally... look at the real history, the Aleph->Accent->Mach set of kernels was from a different tree.
The research program was to see if they could replace the BSD kernel with a Mach-type kernel and get the benefits of new kernel + POSIX/BSD userland... the research was a success. Just tell me what mode that the BSD code was being run in? superviser or user mode? back in the Mach days, BSD code was user-mode code, explicitly not supervisor mode, that was the point. That has likely now changed, but we're debating the origin here, not the current state.
This does not mean that Mach was "derived from" BSD.
Certainly, there is no kernel there and most calls redirect back into xnu. Most functionality is Mach-based, this is just for a user-facing API.
The BSD parts are a POSIX layer on top of that.