On 18/03/14 02:12, Rob wrote:
On 03/17/2014 10:44 AM, Simon Wise wrote:
Any hints appreciated ... an app called juiceSSH has given me a command
line locally, and ssh access to my other machines with a clean interface
and good keyboard support.
I use Connectbot, which is FOSS and offers port forwarding without an
in-app purchase, and VNC to control my machines remotely over ssh tunnels.
I haven't tried JuiceSSH, but as soon as I see in-app purchases I get
concerned about an app.
I certainly prefer FLOSS, but obviously (since I just chose to jump into
Samsung/Google land) I'm not strict about it, I'll try Connectbot. I'll choose
mainly based on how well the keyboard input is handled, and how it behaves as a
terminal emulator. I'll probably end up using bash, ssh etc in XSDL and a debian
chroot, which would be a FOSS solution.
I also have an SSH server installed. I used to use sshdroid, but at some
point they got overzealous about detecting ad blockers (any change to your
hosts file is treated as an ad blocker and the service will fail to start)
so I've switched to SSHelper, which is FOSS. However, my current phone
(Galaxy S4 on Sprint) seems to only do IPv6 on the cell network, if there's
an option to disable that I haven't been able to find it, and I can't get
inbound connections to work with either. But for mounting stuff over sftp,
it works reasonably well on wifi.
that's pretty much all I'd want an ssh server to do, this is more a remote
interface to other computers, I'm more interested in midi, osc, puredata etc
being able to connect via UDP and TCP in an isolated local network, preferably
via ethernet cable, as far as linux audio uses are concerned. And testing USB
audio, potentially using that.
Haven't tried XSDL yet because VNC (x11vnc on the machine being controlled)
is so much faster than forwarding X clients in my experience, but I also
haven't tried getting a debian chroot -- my old phone couldn't handle it, I
only got my current phone a few months ago and haven't had time to root it
yet or put on a different ROM, and I thought all the debian chroot methods
required root.
A terminal for text and compiling is mostly what I want remotely, a gvim window
over ssh -X would be a bit nicer if it wasn't laggy, and I'd much prefer to see
the individual windows than a whole desktop. I have been working on Pis a lot,
running without any X server locally, forwarding any GUI windows for editing
puredata patches etc ... in this case X forwarding is certainly much quicker and
smoother than VNC with a server on the Pi. Likewise I would rather interact with
apps in a chroot this way. In any case whatever is running the window needs to
have a good input driver for the touch/pen and use the android graphics well ..
I'd guess the android VNC apps would do that, I believe XSDL is essentially an
android-native implementation of the X server with an input driver for the
screen, so a lot would depend on how good its implementation is. I'll find out
more as I go.
The chroots certainly don't need root access, an app can set them up ... I
assume that I couldn't set one up manually from the android CL without admin
access, but that I could do so using adb from a desktop (while leaving the local
system without an admin user). That's what I'll try first, it seems a good way
of working.
Haven't yet added an admin account, first I am seeing what is possible
without it. But the command line isn't much use, even man is in /sbin it
seems.
It is very frustrating that even ping requires root, and that devices we
paid for require security exploits to even get root. The excuses even
prominent Android bloggers give (can't damage your device if you don't have
full control of it) are ridiculous, along the lines of advocating
welded-shut car hoods just in case the user gets it in his head to open it
up and put windshield washer fluid in the oil pan, though it wouldn't
surprise me to hear that argument soon in the age of mandatory GPS tracker
legislation.
You can install bash without a full debian chroot, but it's still fairly
limited without the other GNU software, and of course, you're still limited
to doing whatever the phone allows you to.
If all it takes is adding a root password and a few files then delivering
without a root password seems fine to me, even sensible (I haven't looked into
it yet) ... in that case the device is not locked, rather the ordinary user is
very limited and admin access is off by default. Plus the device can be treated
as an embedded device, and administered remotely using adp. Certainly I wouldn't
expect much help from Samsung or Google if I choose to take the system in my own
direction, they have made a default setup and they claim it works well for what
it is sold as, which seems true so far. This is quite different from the
hardware locking that the Windows machines have, especially the ARM ones, where
the OS will not run anything unless the file is explicitly signed by Microsoft,
and the ARM hardware will never boot anything except that OS (the Intel hardware
can be unlocked).
My phone is actually more powerful than the laptop I bought a month after I
got it, so I've thought about Ubuntu for Android or something similar,
something with a bit of effort put into making it usable without a
bluetooth keyboard and mouse (I do have a keyboard case for my phone, but
when I use VNC I always have to zoom in to operate menus and the like, and
right- or middle-clicking is tedious) but the next thing I do will be to
root it and possibly get a better ROM on there, if there is one without too
much functionality missing.
Screenshots of XSDL suggest they have made that effort re touch access to the
pointer in X apps, like having a small area around the finger zoomed in and
two-finger tap for right click. I like Samsung's android pen interface,
especially since I have my old Fujitsu pen with two buttons (i.e. right and
middle click), an eraser end and is a proper pen size. Their handwriting input
is actually quite nice, and quick, for entering text in the various supported
languages.
Android still strikes the best balance between functionality and freedom
for me, but it's nowhere near as open as even Ubuntu, and Google has been
making more and more pieces of it proprietary of late, letting the original
FOSS components languish unchanged in the AOSP repositories.
Re the kernel didn't they move back to adding to the mainline kernel rather than
maintaining a whole separate fork? Otherwise the setup seems to be plugin/module
based ... they have defined an interface for apps, that is the way offered to
build your own stuff, their own interface may well become quite closed source,
like Apple's one is ... I treat the hardware+drivers+interface as something I
buy as is, and refuse to buy if I am locked out of using significant parts of it
without approval from above. I keep noticing they are using unix tools ... for
jackd, wireless tools, dhcp and hotspot tools, plus /dev, /sys, /proc seem quite
populated (but I haven't tested any of it yet). It seems these are more
populated than were earlier versions, given remarks in older threads, so it
seems more of the standard *nix drivers are being used, the ones that run with
linux, so I'd hope their licenses are being respected. Many are BSD licensed of
course, so these can be adapted closed source if Google is prepared to maintain
its own fork, but working with a linux kernel certainly pushes Google to be more
open, Apple chose a BSD licensed base and is much more free to make its
additions closed, and indeed pushes that distinction quite hard.
Simon
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
