It's safe to say that if you're reading this then you know why one would want an SSH server running on your Android device. Personally I have SSH running on all my Linux boxes because it makes life so much easier, and I'm sure I do not need to explain why. Having an SSH server start on boot is simply a lot more convenient!
There are a number of apps on the Android market but most of them are utterly useless with one exception: SSHDroid.
If you are likely to use SSH once in a while then it may be easier for you to just install SSHDroid on your device and start it when needed, and I have been happy with it for a while.
However:
It's an ugly app that sits in your notification tray once it has been started and uses up RAM and CPU. I want a background app.
SSHDroid refuses to run if it cannot access adverts unless you pay for it. I block all adverts because they get on my nerves.
All it does is drop a copy of Dropbear anyway, so you may as well do that yourself.
Dropbear will happily run in the background and uses tiny amounts of CPU when active, so you can imagine how little it does when idle.
If you can compile Dropbear yourself you can choose the options that you want.
As I'm sure you are aware there is no package delivery system for this kind of application in Android, but Android runs on a modified Linux kernel - this makes things so much easier! The result being that the following process is ridiculously easy assuming that your OS has:
su or sudo (root)
init.d support (or another way to run scripts at startup)
The only problem, really, is that the filesystem and methods used in Android aren't exactly standard compared to other *nix systems, but its not massively different. The result being that there are a number of ways that you can get things to work, so I'll simply show you what I have done. If I was doing this to a number of devices or in a corporate environment then I would use a bit more planning.
Google have recently made a whole bunch of changes across most of their platforms to, apparently, integrate more easily with Google+. One of the platforms affected is YouTube. But YouTube also decided to introduce a new video format at the same time, namely 140p (around 32kbps, presumably for dial-up users).
At the exact same time my ISP, O2, sold their broadband network to Sky, more's the pity. I have been informed that there should have been no changes to my ISP in any way... yet.
If that is the case then YouTube is definitely broken.
Nuisance 1
Connection: Ethernet --> ADSL2+
The first problem which became apparent was that the Wii client couldn't play videos any more, or not for more than a few seconds anyway. When it did play it would randomly stop to buffer only a few seconds at a time, and sometimes give up altogether and exit the video. I am not alone: YouTube on Wii keeps buffering. It won't load more than 30 seconds of video.
Nuisance 2
Connection: Any
The second problem was on the trusty browser. In my case Chromium on Ubuntu 12.04.
I seem to have been volunteered to join the HTML5 trial, which I really didn't mind except that it doesn't bloody work.
The video above is Big Buck Bunny downloaded in H264 format at 1080p. It refuses to play in the HTML5 player. To be fair this has only been uploaded a few hours ago and may need time to prepare/transcode/whatever, but as a general rule the HTML5 player fails on videos a LOT.
Switching back to Flash for affected videos can still give the same message, but continually hitting refresh tends to get the damned thing working.
Nuisance 3
Connection: Any
Another problem is that the video will play for a few seconds, usually the magic number of 19 seconds, and then stop, never to continue. Hitting refresh a number of times is required for this to start working too. See the video in Nuisance 4 for an example of this.
Nuisance 4
Connection: Wi-Fi --> ADSL2+
With my 3Mbps down connection I have been able to play 720p YouTube videos for quite a while. If someone else is on the network then it would happily drop down to 480p and play nicely. Not any more!
For reasons unknown the quality jumps up and down, preferentially towards the new 144p format. This is simply ridiculous! At 144p some videos are nothing more than a jumble of pixels. I have deliberately chosen a picture slideshow to show this as quality should be easy to maintain (very little motion). The video is 1080p.
This video shows a typical example of what happens (approximate times):
0:00
"An error occurred, please try again".
0:27
480p
0:37
Video stops altogether as the download stream fails and there is not enough video buffered.
0:45
144p
0:55
480p
1:13
240p
1:45
360p
2:20
144p
Perhaps the ISP or the connection to the router is the problem? Well, I tested this by downloading Big Buck Bunny. This was over Wi-Fi. Caution: this is a very dull video.
tldw; The video basically shows a number of drops in download speed. If I was sensible I would compare this to a wired connection but I don't feel there is any point: the drop-outs are minimal and very short lived. The download (of Big Buck Bunny) is not affected. I also have no other problems with connection on this computer ever. I feel fairly safe to conclude that the signal is not the problem and given that YouTube is supposed to buffer to avoid these problems, that this is not the cause. Uploading is a very similar story. In this instance it's an upload to YouTube of Big Buck Bunny. An equally dull video.
On mobile, the video usually plays quite well, but recently has decided to simply pause for no reason. Hitting play will start it up again but... Nuisance 6.
Not tested over a mobile network yet but I cannot imagine it makes a difference.
On both mobile and web the video should buffer. It doesn't really matter if it does, however. Once paused, either intentionally or because the mobile just felt like it, the video continues to buffer. When clicking play the entire buffer is lost and the video starts downloading again. What the Hell is the point in the video buffering if it's just going to dump the buffer anyway? A wonderful waste of bandwidth.
Pausing used to be useful if I wanted to buffer a whole video in 1080p and watch it in this higher quality. Now it is simply impossible!
The Android app has a solution: pre-loading. Add the video to "Watch later" and it will download the whole video. Annoyingly if you don't watch every video you have pre-loaded immediately then there is a notification on the phone "reminding" you that you have pre-loading enabled and you're not watching the videos. P.I.T.A.
This has never worked. I have a Philips Blu-ray player which comes with a YouTube app (probably Java).
The problem being that the bloody stupid thing makes no attempt to discover the maximum download speed. This means that it will play at the highest quality, no matter what it is. At 3 Mbps my connection cannot handle 1080p (or in some cases 720p) and so continually stops, buffers a BIT (pausing is no use) and then goes through the process again. There is no solution. Even using the Android app the quality cannot be amended.
I thought this app may be maintained by Philips, but it has the same layout as other T.V. apps for YouTube so I don't know who maintains the code. Either way it's cack.
Same equipment as above. The Wii works fine using the Android app as a remote control. On the Blu-ray player it often does whatever the Hell it likes. It nearly always starts the video twice, sometimes three times, and often randomly switches the video. Sometimes it plays a video I played a while ago because it seems to have created a play list and decides to play that from the beginning. The whole thing is just garbage! The responsiveness is generally poor on the YouTube app on this Blu-ray player anyway. The Blu-ray player itself seems underpowered but it plays all kinds of HD files without any problem.
(The Picasa app cannot handle video at all, but makes no attempt to filter them.)
I'm sure there are more but I think I've said enough for now. YouTube is utterly broken!
If the title of this post doesn't mean anything to you, you should probably stop reading.
I'm going to start by assuming you know what Wine is, and pretty much everything else I talk about throughout the post. This is simply intended to be instructional and not educational.
I noticed that there isn't really a full instruction set in the Wine Wiki for how to build a full WoW64 setup within Ubuntu 12.04 64-bit, so I thought I should try and figure these things out for myself. I don't consider this post suitable to be added to the Wiki as it's a bit of a jumble, but I may look into it later. (Feel free to give a helping hand!) It may take a few glances to realise what is being done and why.
The first steps are:
Install all the build requirements on your machine.
Install an i386 chroot (I used Precise again). A fakeroot installation failed miserably but you might have more luck.
Install all the build requirements in the chroot.
Next, you should build Wine64 outside of the chroot.
The 32/64 build will require access to both 32- and 64-bit libraries. This is why it fails in the first place: Ubuntu have screwed up their multilib. You can copy all the files into their respective folder inside the chroot but this will use up more space, and they won't be updated when needed. Soft links won't work and hard links might create problems when running an update. Bind is your answer.
You will need to create the relevant directories inside your chroot:
(Some directories may already exist and be empty - that's fine).
mkdir /usr/lib/x86_64-linux-gnu
mkdir /lib64
mkdir /lib/x86_64-linux-gnu
mkdir ~/wine64
mkdir ~/wine3264
You then need to bind these directories so that the chroot can see them.
(In some cases it would be prudent to bind a directory read-only, unfortunately that fails and you have to mount -o remount,ro /foo/bar if you feel this necessary).
mount -B ~/wine-git /path/to/chroot/~/wine-git
mount -B /usr/lib/x86_64-linux-gnu /path/to/chroot/usr/lib/x86_64-linux-gnu
mount -B /lib64 /path/to/chroot/lib64
mount -B /lib/x86_64-linux-gnu /path/to/chroot/lib/x86_64-linux-gnu
mount -B ~/wine64 /path/to/chroot/~/wine64
mount -B /path/to/chroot/~/wine3264 ~/wine3264
Where you will need to expand the ~ to point to the correct directories.
The final mount being so that you can access the build from your host environment.
I also mounted /tmp as the /tmp inside the chroot will not be cleared on reboot.
mount -B /tmp /path/to/chroot/tmp
Now you can build the WoW64 Wine.
Inside the chroot:
cd ~/wine3264
~/wine-git/configure --with-wine64=$HOME/wine64
make
Remember to add any other options you wish to add.
Once compiled you can run the whole setup from your host environment from the build tree (which has been bind-mounted), or make install and run that way. I highly recommend that you script as much as you can. If you're planning on rebuilding or running regression tests then you will spend a lot of time typing in the same commands over and over.
Similarly, you should consider ccache and distcc. You should read up on how to share your .ccache, and make sure that the distcc servers have the relevant libs too (you could use sshfs mount to work around any missing dependencies).
Also I have added the above mounts to my /etc/fstab so that I don't have to worry about mounting them all the time.
You should now have a working WoW64 build of Wine.
As I have said, this is a quickly thrown together instructional post, so if you get stuck then feel free to ask for help. I highly recommend using irc://irc.freenode.net/#winehq as the people on there are extremely knowledgeable on the subject. If the problem is a little more involved you should probably use the forums.
I'm sure YouTube users are familiar with the blanket copyright notices that are sent whenever music is added to a video.
My video, a fly-by of the Lancaster Bomber at the Sunderland Air Show 2012, had the music "The Dam Busters March" playing throughout. The link being, of course, that the Lancaster was used by the real dam busters and used famously in the film of the same name. I did not add this music: it was playing while the video was being recorded.
Within hours of uploading the video I received a copyright notice via e-mail, and had to defend my use of the audio track. There are a few concerns with this that I will highlight in a moment.
My argument was that the movie "The Dam Busters" was actually released in 1955, and under U.K. copyright law the theme to this film is now in the public domain.
YouTube listened. Actually, YouTube have nothing to do with it. The faceless corporation making the claim agreed, and removed said claim.
This is nice, and everything, but if I hadn't bothered to do the research then my video would have been silenced.
Why do I need to do the research? The people claiming to own the copyrights should know that they have no claim! Claiming that they do is an offence.
How often does this occur? Are companies creating false claims all the time in order to drive people to their websites to increase revenue?
