This is the last post in the series. It has taken me a while to write, edit, and then rewrite because I didn’t like the first outline (which I didn’t realize until I got to the end).
The software I have listed in these posts are there for a reason. While they work well in their own right, when put together, the whole forms something greater than the individual pieces.
Most of the software on the list is lightweight, almost a requirement as one of my systems is a netbook, and although the resources on my desktop seem almost infinite in comparison, I want to be able to work with my things on the netbook as well.
I go for CLI-apps rather than GUIs because that, more often than not, keep my fingers planted on the home row, instead of the right hand scurrying off to the mouse ever so often. Because, more often than not, the CLI-apps are more lightweight than the lightest of GUIs. And because more often than not, a CLI takes up less screen space to convey the same amount of information, as a GUI does.
CLI-based programs will also work when the X-server has broken down, and your stuck in a TTY, or you have your software on a server and are accessing it over SSH from a computer where either you or the system is unable to install the software.
I prefer plaintext over binary storage formats because it leaves me in control. If the worst comes to the worst, I can retrieve the data I need from a simple text-editor.
Not to mention that plaintext is easier to diff, which is good when you check it into version control and run into a conflict.
In the case of LaTeX, one of the best practices I picked up was to let each chapter be its own file, and then have a master-file which includes the chapters.
What this means is that when you want feedback on a specific chapter, you only need to send that, and not the entire project, which is bandwidth friendly.
And please, no comments about fancy gigabit infrastructure all over. You try sending an email or surfing on a long train ride when there are 10+ douche bags hogging all the bandwidth listening to Spotify…
Plaintext is also rather easy to parse. Combine this with a shell script, and your imagination is your only limit to the stuff you could do.
There are definitely more uses for the server, such as VPN and perhaps a mumble server. Time will tell. I do know that I will spend the next couple of days trying to configure nginx and uwsgi so I could start doing some Python web-stuff.
I have been considering dropping Pidgin and instead give bitlbee a try. This would mean that all communication (with the exception of email and microblogging) would instead go through irssi. That would mean one less GUI-app, and also that all the logs would be gathered in one place (on the server) instead of the current situation where Pidgin logs are interspersed between the desktop and the netbook.
I have in a similar fashion thought about replacing Thunderbird with mutt. It would mean that I would replace one software (Thunderbird) with five (mutt, msmtp, offlineimap, abook and mairix).
Well, four anyway, abook is already installed and operational.
msmtp is used to send emails (and thusly communicates with an smtp server.
offlineimap is used to sync an IMAP mailbox (fetch new mails, mark mails as read or deleted on the server, etc)
mairix is a full text search engine for Maildirs.
One of these days, I will also try to become better friends with zsh. It has many nice features which I think could increase my efficiency at least somewhat.
That’s all folks, I hope you have enjoyed reading the series as much as I enjoyed writing it. Comments are enabled in all the post, feel free to add questions or suggestions.