Using bad hardware: why I work in the terminal

08 Sep 2024


It's no secret that the vast majority of my computers that I use for programming or other work are pretty underpowered. My previous daily driver laptop ran an Intel Celeron N4000 and the tablet that I am currently typing this paragraph on has an Intel Atom x5-Z8350 in it.

I've never had a bad experience running this hardware though due to the way I've laid out my workflow for programming as well as my choice of operating system and desktop environment. While I advocate for using a proven workflow that you have built for yourself revolving around the work that you do and the tools you use, often this is not possible with wildly underspecced hardware especially devices with CPUs from the Intel Atom, Celeron or Pentium lines.

The first key component to my workflow is Linux. While I use Arch on a daily basis and as the stock "desktop" operating system on my machines, it is not neccessarily the best distro and any distro that offers you the ability to have a minimal setup out of the box (potentially also called a "server" install) is usable in this instance. I picked Arch for its package manager pacman which I like interacting with, the ease of use of the AUR (with an AUR helper), and its rock solid documentation.

The second key component to my workflow is a window manager. Full fat desktop environments often come with lots of eye candy, built-in utilities, and integration with other applications on your system. While this is useful, this often comes at a cost to both your performance and storage space which is why I prefer window managers. My window manager of choice is i3wm due to it being lightweight, keyboard driven, and easy to configure but other window managers exist like Fluxbox, fvwm, and qtile.

The third and fourth key components work hand in hand being a terminal and a text editor. I used to use nano but have recently taken up using Neovim which is a very comfortable text editor, however coming at the cost of a steep learning curve for new users, and the Alacritty terminal. The reason I prefer using a terminal text editor over a graphical one is that it is universal. I can get my work done anywhere with the same text editing experience whether I am on my daily driver machine, an alternate on-the-go machine, or a server/VM that I happen to be SSHed into because it all works on the same basic principles of the terminal. Terminal text editors are also lighter due to the fact that the terminal is providing all of the windowing fuss for them and that terminals are light applications in and of themselves due to not having to do much that is extremely novel or intensive on a CPU.

All of these components come together to make a text editing/programming experience that is not only portable across many machines but also light on resources and comfortable to use even on extremely underpowered hardware or outdated hardware. My workflow also goes hand-in-hand with my depedency light programming ideals where I prioritise compile times and binary sizes by intentionally trying to pull in as little dependencies as humanly possible which can also help with feature creep by encouraging the programmer to think about each addition carefully.


All content on this website is licensed CC BY-ND 4.0 unless otherwise stated. Copyright © abbieoverflight 2021-2024
Powered by ewfm. This website features no AI-generated content.