The current development version of Coyote Linux is 4.00. This version is being actively worked on and (after multiple restarts and attempts) pretty much all of the ideas and directions that it was moving in for the last few years have changed. I attempted the use OpenEmebedded, OpenSuse, CentOS, SuseStudio and various other sources and/or bases for Coyote development but ended up returning to a build-it-from-scratch approach. Some of the development efforts over the years and the reasons they changed:

  • The use of C# / Mono Runtime – This has been the biggest stumbling block to the creation and release of Coyote Linux 4.0. During the past several years, I have done a lot of consulting and personal development using the C# programming language and learned to really enjoy and appreciate it as a cross-platform development language. As I was actively using both Visual Studio on Windows and MonoDevelop on Linux and the projects could easily be moved from one to the other and back, it seemed like a nice fit for a core language for the system utilities and web front-end for Coyote 4. However, when it came to getting the Mono runtime compiled and installed in small, embedded systems – this idea repeatedly became a major problem. Each new release of Mono required extensive modifications to get it to build inside the Coyote development environment. These modifications and rebuilds ended up taking up the majority of the time I spent working on the new distribution.
  • The use of OpenEmbedded – This was originally started as it appear to contain all of the necessary tools to cross-compile a mini-distribution and also (supposedly) contained the ability to build the Mono runtime as part of the system build process. Although it is capable of compiling for x86 platforms, OE seems to be largely geared toward creating the “Angstrom” distribution for the Arm series of processors. In addition, the Mono runtime package did not compile nor work properly.
  • The use of OpenSuse, CentOS, SuseStudio as a base OS?á- The idea of creating Coyote as an add-on for existing Linux distributions was not entirely ruled out. However, this created a bit of a conflict with the overall design goals for the Coyote project – to be a small, embedded, and secure distribution. The potential attack surface of a full distribution of Linux combined with the mass number of constant updates which would need to be performed simply made it an unacceptable choice for me. Coyote is intended to be used at the network edge – this means that the device needs to be as secure as possible against external attacks and is charged with the task of preventing attacks against the devices which are connected behind it. In addition to the potential security issues, network edge devices are typically expected to remain online, stable, and secure for much longer periods of time than typical systems. It is not uncommon for a firewall to remain online for a year or more at a time. I wanted to retain the potential for Coyote based devices to have year+ uptimes with the minimum possible need to take it offline for updates and/or patches.

The result of all this has been a greatly delayed development and release cycle for Coyote Linux. As such, I have decided to return to the simple system style used in latest releases of Wolverine and Coyote Linux. However, some of the intentions with this release remain:

  • Much more sophisticated hardware detection and support
  • A more modular system design, allowing for the release of multiple Coyote Linux based products and/or appliances
  • A more complete build system, allowing the entire distribution to be built from the original sources
  • Multiple system target types (at this time, specifically both x86_32 and x86_64)
  • Full support for being run in a virtualized or hypervised environment. This will include paravirtualized drivers for at least Xen, VMWare, and possibly HyperV.