In A More Simple Busybox System, I documented how to get started with building a plain old rootfs with Linux, musl, and busybox. While this setup is good enough for local applications, its more practical to fold in some foundational networking capabilities and tools that allow remote access and inspection of the environment.
When learning embedded development, its a good prerequisite to really understand how software is assembled and behaves during execution. I'm not talking about knowing the behavior of if, when, goto, and other high level constructs. When learning how software behaves you should understand the expectations of the instruction set you are using, such as:
For several reasons I have a need for a simple/minimal system that can be used in an existing userspace or as its own userspace. Usually I would jump to tools like buildroot or openwrt for such things. I've used buildroot several times in my other articles for building cross toolchains, rootfs environments, and kernels for several use cases. Instead of going with an end-all-be-all solution like buildroot, I'd like to take a more simple approach that leans more on the tools readily available by the Ubuntu/Debian distribution.
I recently ran into an issue where my Raspberry Pi file share server fell over because of hardware currosion due to some unfortunate moisture exposure. In response, I had planned to replace the file share server with a Mac Mini that was available until I could get a replacement RPi. The service is basically SFTP and the users are responsible for having SFTP clients that meet their needs.
For years now I've always found process to be a facinating area of software engineering. But please don't misunderstand my meaning ... most processes in my experience not only feel painful to the individual contributors but also seem wastful to the overall organization.
By far, the most common use case for a toolchains (compiler, assembler, linker) is for building applications that run on top of an Operating System. A lesser used use case, but still common is to use toolchains for building drivers or modules for the Operating System. What I can only assume is one of the more rare uses cases is using the toolchain to build firmwares that do not have an Operating System. This has become abundantly apparent to me while exploring the possibilities of building firmwares outside of the GNU ecosystem. (Note: I'm focusing on big toolchain suites like LLVM, GNU, and MSVC. I'm aware of other tools like Keil and other proprietary toolchains.)
Its a common pattern to store user authentication tokens in a user's home directory. This way we can login to a service that has a command line interface without having to enter credentials each time we use the command. The one service I know that has done this for me for decades is Subversion. Recently, I've also been logging into services like Firebase, Google Cloud Engine, and Expo.io. All of these services store their user authentication tokens in the user's home directory.
When I work from home, I often find myself working from my laptop for the portability. My laptop doesn't have all the resources that my desktop has, so I normally SSH into a Virtual Box VM that runs from my desktop PC. This works great when I am home, but I've found that on several occasions that I am on the road or not within physical reach of the PC hosting the VMs. Unfortunately, between Microsoft Updates happening more often now, and other things that potentially can cause my PC to reboot itself, I'll wake up to find that I have no connection to the VM I planned to work from.
Started using tmux this year in an attempt to streamline some of my typical workflows. It also is handy to make up for the lack of terminal tab support in VS Code. When I first started using tmux, it became quickly apparent that copy/paste actions are a little more involved. Since I only ever did horizontal splits, I quickly just fell back to holding Shift for everything.
In my previous article on Build Systems for Embedded Development: From 30000 feet., I had concluded that CMake was going to be where any initial efforts would take place. There are a few things that I want to accomplish to prove to myself that CMake can get the job done: