http://www.dyndns.org
http://freedns.afraid.org
http://www.zoneedit.com
http://www.no-ip.com
http://www.easydns.com
http://www.tzo.com
http://www.3322.org
http://www.dnsomatic.com
http://www.tunnelbroker.net
http://dns.he.net/
http://www.dynsip.org
http://www.sitelutions.com
http://www.dnsexit.com
http://www.changeip.com
http://www.zerigo.com
http://www.dhis.org
https://nsupdate.info
http://duckdns.org
https://www.loopia.com
https://www.namecheap.com
https://domains.google.com
https://www.ovh.com
https://www.dtdns.com
http://giradns.com

Let’s see one of them https://freedns.afraid.org. After you register, go to Dynamic DNS link (on the left top box-for members).
Add your host with type A and subdomain and domain what you like as host.

Now there’s going to be a list of your host names. Right click on the Direct Link and copy the link. You should keep the alpha-numeric key. The address will be something like http://freedns.afraid.org/dynamic/update.php?[alpha-numeric-key]

Now it’s time to install the client. I’ve found it from https://github.com/troglobit/inadyn.

1. First of all, install the needed programs to build the service.

$ zypper in gcc-c++ gcc git libopenssl-devel make nano

2. Then

$ mkdir inadyn

$ cd inadyn

3. Download the program from ftp://troglobit.com/inadyn/

$ wget ftp://troglobit.com/inadyn/inadyn-1.99.9.tar.xz

and decompress it

$ tar xvfJ inadyn-1.99.9.tar.xz

4. Go to the directory

$ cd inadyn-1.99.9

5. Compile and install

$ make

$ make install

6. Create the confing file

$ nano /etc/inadyn.conf

with the following content

--username USERNAME
--password PASSWORD
--update_period 3600
--forced_update_period 14400
--alias HOSTNAME,alphanumeric key
--background
--dyndns_system default@freedns.afraid.org
--syslog

The bold words are the ones you should change. Remember the alphanumeric key is the one you got from right click on the Direct Link.

7. Start the client. Create the service file.

$ nano /usr/lib/systemd/system/inadyn.service

8. Add the following content.

[Unit]
Description=inadyn Dynamic DNS Update Client
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/sbin/inadyn

[Install]
WantedBy=multi-user.target

9. Start the service

$ systemctl start inadyn.service

and enable the service

$ systemctl enable inadyn.service

10. Reboot and check if the service is running.

$ ps -A | grep inadyn

you should get results something like:

1526 ? 00:00:00 inadyn

Instructions to run it are same as mentioned earlier. In addition to those you can also use LinuxonAndroid app with patched bootscript.sh. Replace /data/data/com.zpwebsites.linuxonandroid/files/bootscript.sh on your device with the patched one and follow the directions shown here(last 3 images):

openSUSE on android

wget http://www.zq1.de/efika.img.xz # 83MB
xz -cd efika.img.xz | dd of=/dev/sdX bs=1M

with sdX being the device name of your SD-card (e.g. “mmcblk0” on the smarttop itself) with at least 1GB (actually 1024000000 bytes) of free space.

When inserted at boot, it should just boot up within 23 seconds and let you login as root with password “linux” on SSH, serial and with a USB-keyboard on HDMI. I spent some effort on putting as few packages as possible into it. Still, you have zypper to install packages and nano to edit files.

There is still a known hangup when you try to reboot. Workaround is: init 2 ; sleep 12 ; killall rsyslogd ; umount /boot/ ; mount -o remount,ro / ; reboot

As it still uses the original linux-2.6.31 kernel, it has another bug that also happens with pre-installed Ubuntu: sometimes (in ~40% of cases), boot stopps early, before graphics is initialized, when the last line on serial is “console handover: boot [ttymxc0] -> real [tty1]”. Try turning it off and on again.

This should allow you to have a whole lot of fun…

That’s great! But there is a main problem here, I’m not running openSUSE with X11:lxde packages, but debian with their stuff. I cannot use my geeko because the phone is an ARM and our openSUSE@ARM looks to still be in an early development stage. This post wants to be a ping to or openSUSE@ARM project and of course some marketing to this great and light Desktop Enviroment. For people interested in, here some hardware infos:

# cat /proc/cpuinfo
Processor       : ARMv6-compatible processor rev 2 (v6l)
BogoMIPS        : 526.25
Features        : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant     : 0x1
CPU part        : 0xb36
CPU revision    : 2
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 4
I line length   : 32
I sets          : 256
D size          : 32768
D assoc         : 4
D line length   : 32
D sets          : 256

Hardware        : hero
Revision        : 0080
Serial          : 0000000000000000

# busybox free
total         used         free       shared      buffers
Mem:       197016       191024         5992            0            8
Swap:            0            0            0
Total:       197016       191024         5992

But what are these “speedup’s” ? First, you’ve to know that in our build environment the ARM binaries are executed through an emulation-layer. This works on the cost of speed. The goal is now, to exchange some key parts in a transparent manner with native x86 binaries: no emulation, no slowdown. Sounds reasonable, but is it easily possible ?
I had to take care not to mix stuff too much because the environment would break. But now I’ve to say:  WOW, this worked incredibly well  .

The distinctive feature of our approach in comparison to usual cross-build environments is that we use the best of native environment emulation and the speed of cross-compilation. Because of this combination we don’t have to patch the individual packages to make them cross-compilation ready. This is a new way of cross-compiling suitable also for large number of packages. A detailed overview about the different crossbuild types can be found on this page.
Another feature to note is that the exchanged binaries (replacing ARM with x86 in the build environment) also don’t need heavy patching and there’s no need to compile them as static binaries. All of them are normal distribution packages.

A switch in the project enables/disables the new features. With the new changes in place, the speed could be vastly increased. Some figures:
* package rpm
* package glibc w/o locales

Thats a drop from about x15 to x2 in comparison to the native x86 build-time !! See it yourself when the “crosscompiled” repo in Base:build:arm is up and running.

In other words: “Warp 5, Mr. Sulu !”