On Mon, 2014-03-17 at 07:28 +0000, Gordon JC Pearce wrote: $ cat /etc/issue ; uname -m

Am Montag, 17. März 2014, 07:33:04 schrieb Gordon JC Pearce: And then there's a simple and clean Qt4 based GUI app for that task, called Simple Sysexxer: http://www.christeck.de/wp/products/simple-sysexxer/ This works well for me, tested with Roland GR-33 and Korg Wavestation. I'm supplying binary packages for several openSUSE versions and Fedora 19, in my OBS home project: http://download.opensuse.org/repositories/home:/edogawa/ Hope that helps, Edgar

On Mon, 2014-03-17 at 08:46 -0400, Paul Davis wrote: Paul is right, but there anyway is a "halfway house", Arch Linux does provide the Arch User Repository.

On Mon, 2014-03-17 at 09:15 -0400, Joe Hartley wrote: Hopefully it won't cause a flame-war ;). Hardcore: $ yaourt -S "package" When asked to edit the PKGBUILD in my experience, it's usually ok to reply with "no". Using FreeBSD and compiling from a FreeBSD port is much more complicated, OTOH, using yaourt for Arch Linux is disputed ;).

On 18/03/14 00:28, Dave Phillips wrote: Kind of related, but the other end of the GUI v DIY spectrum ... I'm only just now diving into Android ... this year's Samsung Note offering. It is proving a nice device, 4 cores with an additional processor for the pen and a very nice screen. But it's getting very frustrating looking at wizards with three options, none of which suit, then scrounging around a zillion half-baked apps available which may or may not do what I want. A bit like looking through a zillion offerings via apt-get for the first time, but without the quality control, man pages, web pages and community history and support that comes built in with debian. Everything is GUI. Everything is simplified. Very little is possible at any particular step, and the offerings are all context determined so the same path will lead to a different set of choices in slightly changed circumstances. By default, everything non-wizard-ish is hidden, mostly locked away by default, there is almost no documentation. It's all plug and play, or not. The basic things it does built in are done well, the interface is well thought out, flexible and effective, and with a bluetooth keyboard and my old Lifebook pen which is proper sized with an extra button (middle click) all dealt with properly and cleanly it is going to be very nice when I get it sorted. But discover-ability is not there at all. Plus anything out of the standard "be a good consumer" thing may require writing it yourself in Java, or struggling with someone else's undocumented offering which suited their particular needs and device. 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. And the wacom pen works very well, with very nice built in support for handwriting recognition, maths formulas and such ... so the two main reasons I got it are working. I've got an Xserver installed, XSDL, which looks very promising and a debian chroot seems best but which method is the best? I've tested an app which has gimp and inkscape on an xfce desktop, it runs fine, the device copes easily, the (X display from XSDL seems better though, I will use it instead). It is apparently just a debian chroot so this path will be successful. 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. Hints from those who have been here already much appreciated! Simon

On 03/17/2014 10:44 AM, Simon Wise wrote: 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 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. 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. 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. 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. 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. Rob

On 18/03/14 02:41, Patrick Shirkey wrote: ok, adb was next on the list to try ... I'm treating the android somewhat as a remote extension of my desktop, and I'm quite happy doing any setup or installations via the desktop, I'll want to keep the whole samsung/android set of drives and interface, that seems to be done quite nicely, but also want to explore the development side for my own potential uses, so adb is a must. Patrick .. you're in Sydney I think? I've just moved back here after doing a degree in Perth ... I'm based in Ultimo, want to catch up sometime? Simon

On 18/03/14 02:12, Rob wrote: 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. 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. 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. 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). 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. 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

On 18/03/14 22:56, Rob wrote: Yes, I'll let you know. Messing around with the system a bit this evening, the Debian roots I installed from the Play Store (that is a seriously daft name!) are certainly working properly, and I have explored the way they are invoked (standard chroot stuff, just a bit disguised) but they aren't really suited to what I want. They point the way to putting my own in ... they have not required adding root access. Looks like I will do the changes needed via the development interface, rather than mess with the local permissions at all (well ... changing the odd file ownership and turning down the volume on Samsung's "protective" Knox application might make it all more workable). Connectbot definitely does not do it for me ... the local terminal isn't working properly at all, and anyway the interface is all wrong for a 10 inch device and a standard bluetooth keyboard. I'll stick with juiceSSH until Debian and an X server can replace it, keeping it around for those times I want a terminal without a real keyboard. I also tested SSHelper and that is being blocked by Samsung's rather zealous Knox (the icon should be a gilded chastity belt rather than a shield). But the help page suggests a way to simply change its settings behind its back (so the suggestion was well worth it, thanks). I haven't tried that yet but I hope that it is accessible via adb. I had a closer look at what was going on, using the debian chroot, and should be able to undo a lot of the silly restrictions... it would seem that Samsung is more interested in locking things down than Google/Android are, and I certainly want to keep the Samsung drivers and interface stuff fully intact because it is very useful, and I paid them for it so I'd like to keep it, thanks, and without the "helpful" security measures. Simon

On 03/18/2014 10:23 AM, Simon Wise wrote: sftp and shell both work over wifi, but neither work over the cell network. I thought it was due to the ipv6 thing, but today I have an ipv4 address and still can't connect -- and whatismyip.com tells me I have a different address, suggesting that my carrier has me behind a proxy. (That IP address doesn't work, either.) But the stock shell, as you observed, is not that useful, especially without root. So, even on wifi, I pretty much only use it for sftp. I don't seem to have Knox on my phone; I haven't seen the shield, and there's nothing about it in settings. There's a system update that's been pending since I got the phone, and I've been avoiding letting it install precisely because I don't want that. (On XDA's forum for my carrier's version of the phone, there are lots of threads that mention "de-Knoxed" stock ROMs.) Rob

On 03/18/2014 11:20 AM, Hans Wilmers wrote: Well, that sucks. My last two phones (the original Samsung Galaxy S, and before that, the Palm Pre) and my partner's current phone (Galaxy S2) both had/have public IP addresses, which I used all the time because rsyncing to the phone was much more reliable than any of the SCP options I tried on the phone. Must be because the S4 has LTE that they disabled it. Now I'm gonna have to figure something out with Tasker or maybe write an app of my own to set up a reverse SSH tunnel to my colo server. Rob

On Tue, 18 Mar 2014 01:44:20 +1100 Simon Wise <simonzwise(a)gmail.com> wrote: I had a smartphone which was literally eaten by my dog, but before that, I used to download apps from the F-droid repos, which are mostly FOSS. IMHO Android sucks, but the apps in those repos at least don't bother you with ads and nonsense. To be honest, I'm happy I don't have a cellphone anymore... Cheers!