Home photo server, part 1: Server Setup, SCP and FTP

While there are many, many options out there for photo storage, if you are looking for a home storage solution that does NOT involve just plugging in your phone and dumping the pictures to your hard drive, you have to get a little technical. (By the way, if that is what you have to do, there is no shame in it. It is probably a lot safer doing that than letting Google hold all of your photos.)

The first thing I needed was a server. Granted, you could use just about anything these days, and there are a lot of open source/open hardware type solutions, but I was gifted an older, generation 1 Dell PowerEdge 1950 from a friend. Granted, it was made in 2006, but it still is 64 bit, has two quad core Xeon 2 GHz processors, and I loaded it with 24 GB of ram. You can get them on eBay now for about $60. A little overkill for this sort of thing, but the price was right! As a bonus, it supported hardware raid, and I put two 2 TB drives in a mirror array, so that 2 TB of space that was backed up.

From there I loaded CentOS 7 on it per the usual installation method, and updated the system. I also purchased an APC battery backup unit, a Back-UPS 1350. This would only hold the power on for about 15 minutes, but it would help for brown outs, and frequent “blips” where the power goes out for only a second or so, which is common where I live. Later I’ll have to do a post on setting up the auto-shutdown and controls, because that was rather interesting.

So the next thing I needed, if I wanted this to work, was a domain. I needed a way to contact my home computer from my cell phone, especially while not at home. Granted, you could set all of this up so when you come home your phone would automatically back up your photos, but I wanted to be able to do this from abroad. Thus enter No-ip.com. I’ve used them before, and it is great if you are looking for a cheap, cheap solution. Because it is free.

Granted, a free account your hostname will need to be manually renewed every 30 days, but they send you an email, and all you have to do is click the link to keep it active, so it is pretty easy. After creating an account, logging in, getting a dynamic IP address, then all I had to do was install the DUC software. DUC is the Dynamic Update Client software that allows:

“Remote access your computer, DVR, webcam, security camera or any internet connected device easily. Dynamic DNS points an easy to remember hostname to your dynamic IP address.” (noip.com)

All you have to do is download the source code and compile it. It went like this:

$ cd noip-2.1.9-1/
$ make
$ sudo make install

After entering my password, it ran through an installation script and asked me for my account name, password for the account, and which DDNS I wanted to associate with this computer. It is interesting, you can have several.

From here, it then became a matter of preference on how to continue. I toyed with several options on my Android phone for how to get the photos from the phone to the computer over the internet.  One of the first methods I tried was using scp, or secure copy over ssh. So, I installed ssh on my server.

# yum install ssh-server

# cd /etc
# cd ssh/
# ls
# nano sshd_config

I then edited the sshd_config to my liking, there are a lot of guides on this on the internet, so I wont belabor the point here. I will note that I use non-standard ports as a form of extra security, however slight that may be, so you may consider doing the same, but essentially it works as is once installed. Then I opened the ports in the firewall – I list the standard ports here, for ease of following along:

# firewall-cmd
# firewall-cmd –help\
# firewall-cmd –help
# firewall-cmd –add-port=22/tcp
# firewall-cmd –add-port=22/tcp –permanent

And that worked great. Unfortunately, scp is slow and can be cumbersome from an Android phone, especially since I didn’t find any apps that would sync my directories automatically (that were open source so I knew what was really being sync’ed). However, I found several open source options that would sync automatically via FTP. So I decided to install “very Secure FTP”, or vsftp, like so:

# yum install vsftpd

# cd /etc/vsftpd/

# ls

# nano vsftpd.conf

Again, I set it up to my needs, but you can check out this guide for ideas. I also needed to punch some holes in the firewall for the service and for both active and passive mode, since several Android apps would use either.

# firewall-cmd –add-port=21/tcp
# firewall-cmd –add-port=21/tcp –permanent
# firewall-cmd –add-port=20/tcp
# firewall-cmd –add-port=20/tcp –permanent

# firewall-cmd –permanent –add-port=40000-50000/tcp

And viola! All that was left was a quick restart of the processes:

# firewall-cmd –reload

# systemctl restart vsftpd

And now I could use FTP apps on my Android phone to sync my pictures from my phone automatically to the home server! In case you are wondering, a great app for this is on F-Droid, the open source app repository of open source apps. It is called SyncTool, and it is very handy. It supports FTP sync one way, both ways, automatic scheduling or running jobs manually.

Wheeow, that was a long post, but now my photos were being automatically backed up. However, that’s only part of the story, because if I was convincing my wife to ditch Google Photos, I needed to also have a way to browse them online, share them, organize them, etc…. It was time for a web server. Guess we’ll cover that next.

Linux – keep it simple.

Fool’s Mate Friday: The JustChessEngine

Sometimes, you just have to step out in a new direction. In the 1920’s, chess players began to hold to a new style of play, then called hypermodernism. In this phase, conventional moves were called into question, and they began to invent interesting new ways to control the center of the board, without moving the king’s or queen’s pawns. Similarly, I need to re-evaluate the beginner’s chess engine. Question the conventional method that I am currently using, and step out in a new direction. Is that good or bad? Only time will tell.

While writing the Beginner’s Chess Engine, I came to realize that there were a lot of changes that needed to be made to that engine to really speed it up. These changes would be extremely time consuming to implement by direct editing, and called for a whole new engine scheme. Again, I wanted to create a chess engine that was open source, for anyone to use, as well as keep it simple, small, and workable for Android cell phones. Thus enter the JustChessEngine.

Ironically, if you build it from the repository, it will look identical to the Beginner Chess Engine graphically, as I used the same graphical material to create it. However, under the hood is a whole new animal.

You can check out the new repository at https://github.com/alaskalinuxuser/JustChessEngine.

The big change from the git-go is ditching the array of string arrays that make up the board. Arrays are slow in general, and having them in this immutable fashion required multiple rewrites of the board while making a move. So an array is slow, and the Beginning Chess Engine has 8 arrays arrayed in one for the board. This is slow x 8, inside of a slow array. So, I ditched that and started with one array of characters.

Char[] (character arrays) can be edited on the fly, without rewriting the whole array again. As of this writing, the JustChessEngine outperforms the Beginning Chess Engine in speed tests at various ply by three to one! That’s a big gain! Be sure to check it out and feel free to leave comments.

Linux – keep it simple.

Fool’s Mate Friday: A friend helps speed things up….

January 30th, 2004 marked the Guinness world record for the largest networked chess computer. Using the internet to connect with 2070 computers, this networked conglomerate challenged Grand Master Peter Heine Nielsen, and the game ended in a draw!

All that to say that sometimes, we all need a little help. A “phone a friend”, if you will.

As you know, I have been working on the Beginning Chess Engine, an open source engine based in part on a tutorial by Logic Crazy, and have adapted for use on Android phones. Since the start, I have been trying to focus my efforts on making a fully functional and also responsive engine.

Unfortunately, what I have in place right now has a few bugs and is very slow. My Samsung Galaxy S4 can only handle a ply of 3 reliably, with an occasional ply of 4. Even then, these moves can take up to 3 minutes to perform, which is very slow for very little gain, by way of intelligence. However, I just received some great help from a fellow enthusiast, and GitHub-er HenriDellal.

He proposed using editable string buffer’s rather than immutable strings to speed up the computations, and it made a big difference, shaving about 10-20% off of the time needed to calculate the moves!

Using strings, which are immutable (unchanging) caused my old code to create an entirely new string, rather than just edit the existing one. The string buffer can be changed on the fly, speeding the process up immensely. Thanks HenriDellal!

You can see the commit here.

Linux – keep it simple.

Geany: the little IDE that could!


Recently, while working with some older equipment, I needed a lightweight java IDE to compile some java projects. I really wasn’t looking for something quite as big as eclipse or netbeans, I just wanted a simple, one stop solution that would allow me to build java programs on an older laptop.

So, I rubbed a magic lamp, and out popped Geany!

Well, more specifically, the laptop is running Debian Wheezy, and had openJDK already installed. With that alone, I could have built java programs from the command line, but it can get a little tedious. So, I looked on the repositories for an IDE that wasn’t too large.

Thus enter Geany. I first used Geany a long time ago as a text editor on #! (CrunchBang) Linux, but revisiting the program revealed that I was not using it to it’s full potential. Specifically, you can compile, build, and run various program types from within Geany. Of course, it only outsources the commands for you, so you need a java jdk in order to compile java, or a c++ compiler to compile c++. Geany just does all the command line work for you.

What Geany does accomplish for you, however, is a great user interface with templates and the ability to organize projects or view code with different filters. As you can see in the picture, I was testing out Logic Crazy’s Alpha Beta Chess program.

As well as showing you the code, it can do parenthesis highlighting, colors for different code type, and a class and method tree on the side. It really is a great program if you need a lightweight IDE. I know that I’ll be putting it to good use.

Linux – keep it simple.

Fool’s Mate Friday!

Occasionally, I do a theme, or idea, on a given day for a period of time. Currently, I have been spending quite a bit of time working on chess engines and their play. So, I am going to create a “Fool’s Mate Friday” post. That’s right, every Friday, I’ll be bringing some small tidbit about programming chess engines, or chess games, or chess play in general. So, stay tuned for Fool’s Mate Friday!

This does bring up two important questions, though:

#1. What is a fool’s mate? Well, a fool’s mate is technically a check mate that happens in 2 moves. However, by extension, it can be used to refer to any set of opening moves that lead you to a checkmate very early in the game. Typically, it is specifically a reference to being checkmated by making poor moves on the fool’s part, rather than tactful moves on the winner’s part.


Technically, this would require 3 moves, and is thus a fool’s mate by extension, rather than by definition. 1. e3 f6 2. Qe2 g5 3. Qh5#.

#2. Why name it “Fool’s Mate Friday”? Two reasons, really. I needed a chess related term that started with F, and this is fairly accurate, as I am an unrated player of low standing (and understanding) in the game of chess, and my programming skills are not that good yet. Both of these lead me to make many mistakes, both in the game and in the programming thereof, which is certainly on par with the fool’s mate.

Linux – keep it simple.

Making an Android chess app….


Lately I’ve been amusing myself in my spare time by learning how to make a chess engine. I don’t want anyone to think that I came up with this on my own, I’m taking a tutorial through Youtube videos by a man called Logic Crazy. Be sure to check out the link for his tutorial, I’ve found it to be fun and informative!

Logic Crazy seems to have a website with several other variants of chess engines, as well as engines for a couple of different games. And that is also worthy of a good long look. For myself, I’m just trying to learn the basics of Java programming.

Logic Crazy’s design is for an actual Java program to be run on your computer. I on the other hand, am adapting it for an app to be used on an Android phone, which I’m hoping will be fun, but also a great learning experience. My free time is a little bit limited these days, but hopefully you’ll be seeing more posts about it soon.

Linux – keep it simple.

Critical Velocity – an open source libGDX game that was crashing on small screens is now fixed!

Critical Velocity is a fun little open source arcade style scrolling game that I made after finishing my Android developer class. It was my first released game using the libGDX engine, an open source graphics engine that is great for making games. Due to my inexperience, however, I didn’t take into account that all screens are not created equal. Some screens are bigger than others, and some have lower resolution than the phone I built the game on.

This caused a problem. After releasing the game, I quickly was alerted to the issue through the GitHub issue tracker, where several players let me know that it was crashing on startup with their phones. It took a little bit of time to figure out, but I came to realize that the app was crashing on phones that were smaller than 800×480 screen resolution.

At first I thought there were all sorts of problems with graphic asset sizes, and memory issues. I tried numerous things to fix it, but nothing worked. Finally, I gave up. But, a few days ago, I decided to take another look. By God’s grace, this time I got it figured out! Before, I was working off of the information provided by people with smaller resolution screens, but I decided that I should load up the game in an emulator with a 320×240 resolution screen, and watch the logs. That’s when I found the problem.

The issue didn’t have anything to do with libGDX, the graphic assets, or the amount of memory the game takes (about 15 MB). As it turns out, the math just didn’t add up. Literally!

In the game, the upper and lower walls are separated by a gap. The size of the screen and the size of the gap is used to determine where the next set of walls opening can be (up or down) from the previous wall. The idea was that as you went faster, an opening at the top of the screen followed by an opening at the bottom of the screen is technically impossible to reach, so this math would keep it “near” the other opening within reason, but still allow it to be randomly placed, up or down from the previous one.

The math looked like this:

Place of the next wall opening = randomly based off of (1/2 of the screen height – the size of the gap) from the center of the screen.

This worked great on my test phone that had a screen resolution of 1920×1080. With the standard gap that I set of 450, the math looked like this:

Place of the next wall opening = randomly based off of (960 – 450 = 510) from the center of the screen.

But it didn’t work for a screen as small as 320×240 because:

Place of the next wall opening = randomly based off of (160 – 450 = -290) from the center of the screen.

For a random number, you can have a negative outcome, but you cannot put in a negative input. The random number is based on starting at 0, and create UP TO X random numbers. So if X is negative, then the random number generator doesn’t know what to do!

So I had to invent a way to fix this problem. Fortunately, that was easy. I used an if/then statement to ask what the screen size was, and then changed the gap size to be less than 1/2 of the screen size. I also had to edit a few parameters, such as thrust, speed, and distance also based on screen size. You can check out my code and commits here and here, if you’d like.

Long story short: Don’t make assumptions, check the logs and they WILL lead right to the problem! If I had run the emulator myself before, not having a small screen phone anymore, I hopefully would have seen this right away. Here are some screen shots of the game on different phones. Unfortunately, I still have a lot to learn to make sure that the game LOOKS the same on different sized screens, but at least now it doesn’t crash!

Linux – keep it simple.

Adding the ability to SatStat to copy the current location to the clipboard

If you like open source applications, and use GPS on your phone, you probably have heard of SatStat. It is a really great open source option for monitoring your location with GPS, as well as several other nifty perks. The only downside I could see to this application, is that it did not have a way to copy your current location to the clipboard so that you could share it with someone else.

Often, when using this app, I end up taking a screenshot of my location and sending that to someone else, but this is very tedious for them in the form of wasted data transmitted that they now have to manually sort through and retype the coordinates of the picture into a text format for use in a GPS app or Google maps.

So, I decided to quit whining and do something about it.

It was fairly simple, actually. You can see my commit here. All I did was fork the SatStat GitHub, download the fork, and added a menu option to copy the current location ( the one being displayed to the user) to the clipboard. I followed that up with a pull request, which also updates the referenced issue tracker, where other users were requesting this function as well.

I could have actually used the “location” that was being reported to the system, rather than the displayed location, but I did it by displayed location for three reasons:

  1. If there is no location information from the system. The displayed location still has  ” – – ” displayed in it. So, the copy to clipboard command will not error, because it will simply copy ” – – ” as your location.
  2. The user has the choice of how the location is displayed. Rather than weed through all the settings and then copy the system reported information, and then edit it to match the user preferences for display, it simply copies the text as displayed, which already is per the user’s preference. I figure if they wanted it to be in MGRS, or decimal minutes, they would already have set their displayed information to that.
  3. To keep “what you see is what you get”. The location displayed to them is exactly the information they will copy to the clipboard. This helps in the event that the information displayed is not updated, they can copy the last known location, as the information displayed is only updated when the location has changed.

I tried to keep the code as clean and simple as possible. Hopefully they will add that to the regular app. If not, well, I suppose that I will just start using my edited personal copy, so I can save my own position to the clipboard.

Linux – keep it simple.

Installing the latest PicoLisp on Ubuntu

While testing out The Quiet Learner‘s game, Dr. Theobold, a text based adventure game written in picolisp, I ran into several issues. As discussed previously, I added these issues to the bug tracker on Savannah. Come to find out, the distributed packages for Ubuntu are using version 15.xxx of picolisp, and The Quiet Learner wrote his program for version 16+. We needed to find out if the old version was the culprit, or if there truly were issues in the game.

So, I updated to version 17.7.6 (a rather interesting numbering, since I tried this the 4th of July week, but that is something else entirely).

As simple as the above statement was, my trek was not quite as simple. I am used to compiling programs. Typically, you start by unzipping the source, using ./configure, then make, and sudo make install. However, this was different.

Of course, I downloaded the source from the link in the PicoLisp Wiki. After that, I unzipped it with the standard

$ tar -xzvf ./picoLisp.tgz

and moved into the new director with

$ cd picoLisp

Once there my usual bag of tricks didn’t work, which is why it is always good to read the instructions. Ends up that I needed to cd into the src64 directory and run make. No ./configure first.

$ cd src64

$ make

And there was no option to make install. Instead I had to manually symbolically link the files, and that is where everything went wrong. You see, the INSTALL file had pre-typed instructions with all 3 links you could use, like so:

# ln -s /<installdir> /usr/lib/picolisp
# ln -s /usr/lib/picolisp/bin/picolisp /usr/bin
# ln -s /usr/lib/picolisp/bin/pil /usr/bin

But after doing that, it didn’t work. It didn’t work because I forgot that the directory was picoLisp, not picolisp. I chased my tail for a while, re-creating the same bad links over and over again until I realized my mistake. Since /<installdir> was not the directory (obviously) I was hand typing picolisp, and it wasn’t working. So, be smart and not like me. Do as I now say, not as I erroneously did!

After straightening it out, it worked great! Actually it cleared up 3 of the issues that I put on the tracker for the Dr. Theobold game. I guess it pays to have the latest and the greatest when it comes to PicoLisp!

Linux – keep it simple.

MechDome reaches out to open source app developers

MechDome, the new way to convert your Android application into an iOS app. While still somewhat in development, MechDome has been making great strides in the field of app converters. The best part is that MechDome doesn’t use your app source code, it uses your completed Android apk file to churn out a completed iOS application!

If you are interested in knowing more about the process involved in converting your Android app into an iOS one, you should read my previous article, where I gave it a go. I have to admit, it worked out rather nicely! I’ve converted two applications on their website, and so far, both worked great in the simulator!

Yesterday, MechDome sent out a newsletter informing everyone that they are starting an open source developer program! As an open source developer, I get really excited when I see companies supporting open source work. If you read my previous article, you can see where I made a few suggestions to MechDome in regards to open source development. Here’s a quote from that article:

  • Ideal: Give users the opportunity to create an open source developer account that can convert a limited number of open source apps per month, such as two or three, for free. No subscription costs, and if the account stays active, then it will not expire.

  • Less than ideal, but still helpful: Give users who already have paid subscriptions the ability to convert open source applications without counting against their monthly quota or subscription.

  • A one time setup cost: Another option might be a one time cost, rather than a subscription, for an open source account. E.g., a $25 setup fee for open source users to set up a developer account.

Based on their letter, it looks like they chose a slightly different direction, or perhaps a “modified” version of my third option. They decided on a flat fee of $25 to allow you to convert one open source app.


I think that MechDome is on the right track. I do appreciate how they are reaching out to open source developers, and although a one time fee per app of $25 isn’t free, it isn’t ridiculous, either. I could see how larger, community driven projects, or ones that accept donations might be able to foot the bill for app conversion, it just is not as convenient for small timers like me. I guess we will just have to wait and see.

Linux – keep it simple.