kugelfish

What I still miss the most after moving from G+ to Diaspora* for a my casual public social network posting is a well integrated mobile app for posting on the go. The main use-case for me is posting photos on the go, which I now mostly take on my cellphone and minimally process with Google Photos. One of the problems with the mobile app for Diaspora* (Dandelion in the case of Android) is that the size limit for photo uploads is quite small compared to the resolution of todays cellphone cameras. There is also not much point of uploading  high-resolution images for purely on-screen consumption to an infrastructure managed by volunteers on a shoestring budget. I also liked the ability to geo-tag the mobile posts by explicitly selecting a nearby landmark to obfuscate a bit the current location. For a few weeks now, I have been sharing my account with a  G+ archive bot  that is uploading recycled posts from the takeout archive (see here for the first part of the series ...

<- Part VII: Conversion & Staging The last stage of the process is to finally export the converted posts to Diaspora* the chosen target system. As we want these post to appear slowly and close to their original post date anniversary, this process is going to be drawn out over at least one year. While we could do this by hand, it should ideally be done by some automated process. For this to work, we need some kind of server-type machine that is up and running and connected to the Internet frequently enough during a whole year. The resource requirements are quite small, except for storing the staged data which for some users could easily be in multiple gigabytes, mostly depending on the number posts with images. Today it is quite easy to get small & cheap virtual server instances from any cloud provider, for example the micro sized compute engine instances on Google Cloud should be part of the free tier even. I also still have a few of the small, low power Rasbper...

Linux is a multi-user, multi-tasking based system, which means that even a computer as small as the Raspberry Pi, can be used by multiple users simultaneously and there can be multiple processes executing (seemingly) all at once. For example, here are all the processes currently running for the user pi: pi@raspberrypi ~ $ ps -fu pi UID        PID  PPID  C STIME TTY          TIME CMD pi        4792  4785  0 Mar11 ?        00:00:04 sshd: pi@pts/0    pi        4793  4792  0 Mar11 pts/0    00:00:04 -bash pi        6137  6130  0 00:30 ?        00:00:00 sshd: pi@pts/1    pi        6138  6137  1 00:30 pts/1    00:00:01 -bash pi        6185  4793  0 00:32 pts/0    00:00:00 tail -f /var/log/mess...

In the previous two episodes about IP networking, we have seen a lot about raw addresses and port-numbers, because that is how the networking stack operates internally. But this is not how we interact with the Internet in real life. Except for trouble-shooting, we don’t typically use raw addresses and IDs but rather names. For example, instead of http://173.194.113.115:80 , we would enter http://www.google.com . In the earliest days of the Internet, people kept a list of name to IP address mappings on each computer connected to the network, similar to having each a copy of a phone book. The remnants of this file still exists today on Linux in /etc/hosts for some special local default addresses. pi@raspberrypi ~ $ cat /etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback 127.0.1.1 raspberrypi Beyond that, it is hardly used for name management except for the smallest networks with only up to a few hosts with static IP addresses. Domain Name System (D...

Today, we are taking a look at the TCP/IP Internet protocols by using a few commands which allow us to see what is going on in the Linux kernel, all the way down to the Ethernet wire. For example, the basic ping command we have seen in a previous post might result in the following sequence of packets sent on the Ethernet port of the Raspberry Pi: ARP, Request who-has 192.168.1.143 tell 192.168.1.148, length 28 ARP, Reply 192.168.1.143 is-at c4:2c:03:1c:f2:2e, length 46 IP 192.168.1.148 > 192.168.1.143: ICMP echo request, id 17785, seq 1, length 64 IP 192.168.1.143 > 192.168.1.148: ICMP echo reply, id 17785, seq 1, length 64 IP 192.168.1.148 > 192.168.1.143: ICMP echo request, id 17785, seq 2, length 64 IP 192.168.1.143 > 192.168.1.148: ICMP echo reply, id 17785, seq 2, length 64 But before we are trying to understand what is going on here, a brief excursion into the history and theory of packet networking. In the 1960ies, researchers were starting to think of ...