When I first obtained a CompTIA A+ certification some time ago, the concept of bit rot related to what happens to software reliability as the number of updates to the system increases. Over time, software that worked in years past ceases to work as new system updates block system calls or change permissions and files that the software originally relied upon. This slow decaying of reliability was called bit rot. There are some other definitions floating around on the internet, but that is the one most relevant for me.
To prevent this and reduce the amount of time spent in sorting out the bit rot introduced to my investments by Microsoft’s proclivities, I have standardized on two operating systems for major time investments in computing that occupy my life. Windows still has a place since I sometimes use Windows only games to play with my child. Other than that necessity, I have built the things I rely on for use with Linux. The two versions that I have standardized on are Debian and Fedora. Specifically Debian 12 and Fedora 38. These are not what is used for the website, but they are the major components of my anti-bitrot infrastructure. I am aware this may not be good security practice, but this isn’t to get me a job, this is to serve an aging man and his family reliably over time.
There are a few reasons that I selected Fedora 38 and Debian 12. Fedora 38 still has Python 2.7 in the repositories. It was within 2 versions for upgrading from Fedora 36. Fedora 36 was what I was running in my Windows Subsystem for Linux instance, and I upgraded it to Fedora 38. When deciding to move back to bare metal for my Linux software development and automation needs, I decided to standardize on that one. Debian has a 32 bit version. I have both the 32-bit and 64-bit deployed in my network. Debian 32 bit allows on to easily 32-bit builds of Java on a Linux server. One can add the testing repository and have the latest Java in 32 bit form. 32-bit Java is necessary to run older Minecraft versions. My family has a large set of mod-collections and old Java Minecraft instances and maps going back about 8 years. I can then run the latest JVM and the latest Minecraft on the same server because the 32bit JVM is available. It is very annoying to try and manage 32bit and 64bit Java virtual machines on the same host, so having it all 32-bit solves a huge problem. One can add the Debian 11 repository and install Python2.7 if one wants to use old Python versions. I need this old Python version for a project that I worked on over the course of the last 8 years.
The general anti-bit rot measure for Debian is to always use apt-get to install packages as this will leave the .deb file in the cache. Then copy those .deb files on a regular basis to another location for use as a repository for other Debian installations. This can be configured to work via a cron job. Debian is really the only long-term viable game in town if one wants a 32-bit anti-bitrot bunker that will last into the future, over say, a ten year time horizon. Save the .deb files on a private web-server inside the network and periodically update that repository with the files copied via the sweeps from the cache directory.
For Fedora, this should work with any version. Fedora 38 is the one I use. Edit the /etc/dnf/dnf.conf file to say keep_cache=True, and this will save the dowloaded RPMS. One can then build their repository using only what they need if so desired. The other genuine long term standardization option is to mirror the entire repositories to the private webserver within one’s network. To do this, install yumdownloader. Then, move all of the .repo files from /etc/yum.repos.d except for one to a temporary location. Then, go into a directory with a lot of space. For Fedora 38, the complete mirror was 229GB. Then use yumdownloader * and it will download all files from that repository. Then, use yumdownloader –source * and it will download all source packages for the packages that it just downloaded. Then, go back to /etc/yum.repos.d and switch that .repo file out with one that was moved previously, and repeat the process until all repositories have been completely downloaded. Then, copy all downloaded RPMS to one large directory on the webserver and use createrepo to create the meta data. Then on the client machines, create a .repo pointing to your own webserver, and move the existing .repo files in /etc/yum.repos.d to an archival location. Then all of your installations will occur from your own webserver and all machines will have the same versions of packages.
In my case, I then install the data science specifics that I need for the automated software that I created. The process varies slightly depending on whether the system is Fedora or Debian.
For Debian:
Add bullseye to sources.list
Install python2 via bullseye repositories
Install pip via the downloaded file from https://linuxhint.com/install-pip-on-debian-11/ that is to say,
1. wget https://bootstrap.pypa.io/pip/2.7/get-pip.py
2. python2 ./get-pip.py
Apt-get install libcurl4-openssl-dev
R:
Install.packages(‘curl’)
Install.packages(‘fpp2’)
Install.packages(‘magrittr’)
Install.packages(‘urca’)
Install.packages(‘vars’)
Install.packages(‘psych’)
Apt-get install r-cran-rjava
Install.packages(‘rJava’)
Install.packages(‘xlsx’)
Install.packages(‘Hmisc’)
Install.packages(‘prophet’)
Install.packages(‘dplyr’)
pip2 install parsedatetime==2.5
apt-get install awscli
pip2 install boto3
apt-get install r-cran-car
Troubleshooting steps if .xlsx and others are not built:
Are all R packages installed successfully with a 0 exit status?
On Fedora, the repositories do not contain R components in the same way the Debian repositories do. Here is the process for Fedora 38.
Used the script https://bootstrap.pypa.io/pip/2.7/get-pip.py
pip2 install parsedatetime==2.5 –user
dnf install libcurl
dnf install libcurl-devel
dnf install R
dnf install awscli
pip2 install boto3 –user
dnf install cmake
Within R:
install.packages(‘car’)
install.packages(‘curl’)
install.packages(‘fpp2′)
install.packages(‘magrittr’)
install.packages(‘urca’)
install.packages(‘vars’)
install.packages(‘psych’)
install.packages(‘rJava’)
install.packages(‘xlsx’)
install.packages(‘Hmisc’)
install.packages(‘prophet’)
install.packages(‘dplyr’)