|
The Vulpine Group is an independent United Kingdom and Europe-based software collaboration founded by Charlie, and shortly after Taylor under the BaronScott Consortium.
We build "On Linux 4 Linux" creating purposeful, terminal-first software that avoids unnecessary complexity while respecting user privacy and freedom. At Vulpine we aim to provide a lean, purpose-built suite of software for engineers, developers, system administrators, and embedded deployments such as our Vulpine Linux OS, steering clear of corporate “agentic” systems, invasive advertising, and strict tracking. We operate purely on a no-profit/low-fund model and as such any donations go towards keeping the proverbial lights on, and minor costs such as the occasional coffee more than anything, paying back startup funds for getting the servers rolling, etc.
Vulpine Linux follows a rolling development model, with packages being updated as new stable upstream releases become available after review and testing. Each package introduced into our package manager is tested on a memory-only virtual machine, a full-install virtual machine and lastly a hardware installed machine. Rather than chasing the newest software for our own sake, Vulpine prioritises stability, re-producibility, and maintainability while remaining current with modern Linux technologies which we support.
The distribution is built around a lightweight environment and a purpose-built package ecosystem maintained by the Vulpine Group and volunteers. Core software including cvsh, vpm, networking tools like wpavulp, development utilities, and desktop components are maintained with an emphasis on minimal downstream modifications, allowing users to benefit from upstream improvements while preserving consistent behaviour across the system.
Vulpine embraces modern technologies where they provide clear technical advantages, but avoids introducing unnecessary layers of abstraction or software whose complexity outweighs its benefits. New technologies are adopted because they solve real problems and not because they are fashionable or the latest trend.
Vulpine Linux is guided by practical engineering rather than ideology. Design decisions are based on long-term maintainability, security, transparency, and technical merit. Features are evaluated individually, with preference given to solutions that remain simple to understand, easy to audit, and straightforward to maintain. Where possible Vulpine Group prefers to develop solutions internally, and first-hand rather than becoming dependent on other maintainers or developers; where we do depend on them we always choose the battle-hardened and ready route. Software that has aged like wine and with grit.
Where upstream software aligns with the goals of the project, it is adopted with minimal modification. Where software becomes unnecessarily complex, difficult to maintain, or conflicts with the project's philosophy, alternatives may be developed in-house - as demonstrated by projects such as cvsh and vpm.
Every addition to the operating system should justify its presence.
Vulpine Linux is built for users who value understanding their systems and want inherent minimalism and security features.
Rather than hiding system behaviour behind graphical interfaces or automation, Vulpine provides predictable tools that encourage learning and direct system administration. Documentation is considered an essential part of the project, and users are encouraged to understand the software they run.
Contributions from the community are welcomed through the project's Forge and Codeberg mirrors, reports made over IRC or Discord. All submitted code is reviewed, commits must be cryptographically signed, and contributions are expected to follow the Vulpine coding standards and project philosophy.
The project remains community-driven, with development led by the BaronScott Consortium - notably Charlie - and supported by volunteers who contribute code, documentation, testing, and user support, among other factors. Some on a more official basis than others.
You can't trust a system or software without a face; so meet the people behind it!
Charlie BCS - Leadership, Software Engineering, Cyber Security ('staff')
Original founder, platform architect, and cyber security specialist. Holds a British Chartered Institute of Technology post-nominal and champions transparent protocols and user freedom. With previous experience in operational security, development and project management, a hobbyist in astronomy and astro-physics. Notable avid enjoy-er of history.
Taylor MSci - Software Engineering, Support ('staff')
Assisting in research-predominantly in post-quantum grade and systems cryptography. Aiding in back-end infrastructure and ad-hoc programming on various projects across the Vulpine Group. Holds an MSci in Applied Mathematics and Theoretical Physics (QUB purser studentship award). With a preference to code and read quietly in the corner without disturbance.
Martin - General Support and Software Engineering (volunteer)
A long history in programming and language development. Acts as a key support pillar on Discord, reviews commits, and champions open standards and professionalism. Readily willing to assist and give input regarding project direction and public perception; and keeps us all humble.
Brego Bachelor of IT - Software Engineering (volunteer)
Joined following the initial few indev releases of Vulpine Linux OS and had instrumental contributions past Phase-I/II, building out the initramfs boot with Charlie, aiding in binary permissions, and ported CVSH (shell) to being a standalone c-language shell, rather than being dependent on SH. Strong believer in the "suckless" and "keep it simple" philosophy.
Vulpine (Linux OS): A minimal, immutable, terminal-first operating system designed to be understood end-to-end.
Charlies Shell (CVSH): Our POSIX-inspired shell written specifically for Vulpine Linux, revised by Brego.
VPM: Native package manager designed around small, reproducible packages which works on none-Vulpine systems as a lightweight stand-in for multi-distro package management.
Audit our code or contribute via our Codeberg mirror.
Socks: A lightweight automation and moderation solution designed specifically for Discord communities, built with the same philosophy of simplicity, transparency, and intentional design. Running on a Vulpine Linux OS virtual-machine as a showcase of real-world use case!
The seeds of Vulpine Linux were put into the ground in 2025 when Charlie began developing minimalist initramfs based systems as a way of better understanding the Linux Kernel, that seed became the root in which Vulpine was founded in 2026 by Charlie, with Taylor joining shortly afterwards to form the BaronScott Consortium. The project began with a straightforward objective; build a Linux distribution that remains understandable end-to-end, avoids unnecessary complexity, and places users - not automation - in control of their systems. Removing en-mass corporations from your environment.
Unlike many modern distributions, Vulpine was never intended to become a large commercial platform or enterprise operating system. It is developed as an independent collaboration funded primarily through community donations, with all proceeds supporting infrastructure, development costs, and the continued operation of project services.
From its earliest development, Vulpine adopted several core principles that continue to define the project:
Early development focused on producing a complete operating system using software written specifically for the project wherever practical. This resulted in the creation of cvsh, the Vulpine command shell, and vpm, the native package manager designed around reproducible package builds and straightforward package management in a light-weight way.
As development progressed, volunteers joined the project to assist with package maintenance, documentation, infrastructure, and software engineering, while preserving the project's small-team philosophy. Today, Vulpine Linux continues to evolve as an independent distribution, maintaining its commitment to simple engineering, transparent development, and software that can be understood, audited, and maintained without unnecessary complexity.
Vulpine is presently not a charity, foundation, or formally incorporated entity - it is a direct collaboration between Charlie and Taylor under the BaronScott Consortium we started together; as such parties outside of them are volunteers, and major direction decisions involving monetary supporters are carried out via email or website voting where consensus is required.
We use a "fork-and-contribute" method via our Codeberg mirror.
Mandatory: All commits must be signed (GPG/SSH) at sign of committal. Unsigned commits are strictly rejected.
We maintain a strict but fair Anti-AI Clause.
Focus on one branch per feature or fix with clear git -m messages.
snake_case when possible.job_count, format_size(), load_config()PascalCase for typedef names. Always use anonymous structs when typedef-ing.CvshConfig, Manifest, PackageAn example would be:
typedef struct {
char name[64];
char version[32];
} Package;
UPPER_SNAKE_CASE for #define constants and macro values.MAX_INPUT_LENGTH, DB_DIR, TOK_WORDsnake_case.g_ (for global) prefix is acceptable (e.g., static int g_lock_fd = -1;).Whilst that covers typical naming conversions and expectations regarding Formatting and Indentation, we typically aim for the following expectation and we kept it simple.
Indentation: Use consistent indentation, code bases should use a tabs, evident in cvsh , or 2-4 spaces as evident in vpm but no other derivatives. When working in a specific file, match the existing indentation if ever in doubt tabs is what we prefer.
Pointer Asterisk Placement: If the code base contains both char* var and char *var, it should be changed to char *var. When dealing with arrays of pointers or function arguments, char *var is preferred.
An example would be:
int *a[10];
int (*a)[10];
char *(*f)(void);Brace Placement is another important one to cover, as Functions braces can be placed on the same line (with K&R style, prevalent in cvsh) or on a new line (Allman style, prevalent in vpm). Follow the convention of the specific project you are editing but it is preferable however to use Allman style format as it allows for comments beside each line, rather than above/below aiding in readability.
An example would be:
#include <stdio.h>
#include <stdlib.h>
int check_threshold(int value)
{
if (value > 100)
{
printf("Value exceeds the maximum threshold.\n");
return 1; // Returns error code if value is too high
}
else if (value < 0)
{
printf("Value cannot be negative.\n");
return -1;
}
else
{
printf("Value is within acceptable limits.\n");
return 0;
}
}It is worth mentioning that Control Statements such as if, while, and for loops, should leave a space between the keyword and the parenthesis: if (condition).
Single-Line Conditionals on the other-hand are unique and braces may be omitted for single-line blocks with short, early-return conditionals place entirely on one line:if (!file) return;. As these can be easily commented on as they're short, and often simple.
Otherwise, place the single statement on the next line:
if (fd < 0)
die("db");String and Memory Safety matters a lot particularly Buffer Allocation as it posed quite the road-block in early development with cvsh we prefer fixed-size stack arrays over dynamic memory allocation (malloc/free) whenever the maximum size is known and reasonable. As we found this works best in our development pipeline so far.
An example of this would be: char path[PATH_MAX];, char wordbuf[WORDBUF_SIZE];
sprintf or strcpy. Always use snprintf to prevent buffer overflows, and ensure you pass the sizeof(buffer).snprintf(path, sizeof(path), "%s/.config/cvsh/cvsh.conf", home);!strcmp(a, b) or strncmp(a, b, len) == 0 for string comparisons rather than comparing against 0 explicitly.if (!strcmp(p.name, name))Path Manipulation is a serious concern for security reasons, do not concatenate paths manually using string operators. Use safe wrapper functions (like vpm's path_join) or snprintf to build paths securely!
This brings us into Error Handling and System Calls, if you've made it this far and past buffer allocations, chances are you'd run into the odd overflow or bug so its helpful to understand how we expect them to be handled.
die(const char *msg) function to handle unrecoverable errors. This function should print the error (usually wrapping perror()) and exit the program (exit(EXIT_FAILURE)). Doing so as cleanly as possible.fork, open, mkstemp, execvp, stat, etc.).Check for strictly negative values on file descriptors and process IDs: if (fd < 0), if (pid < 0).
Return Codes: Functions that indicate success/failure should return 0 on success and 1 (or -1) on failure. Do not use boolean true/false macros.
if (fd < 0)
die("db");In the event Functions return -1 for errors, test against 0 and not -1 as a safety measure.
Software Versioning is in every project, and must include a globally accessible version string block near the top of the main file. This is vital for the automated .vpm pkg build system we have in place and ensures it runs smoothly.
This block must include the following standardised comments tracking the Semantic Versioning intent - it is vital this is updated with every iteration you've made. You can even copy-paste this block specifically if you prefer replacing the x.y.z values accordingly:
// Increment based on Software_versioning
// MAJOR (2.x.x)
// MINOR (x.5.x)
// PATCH (x.x.14)
// Dependent on work carried out during your revision
// https://en.wikipedia.org/wiki/Software_versioning
const char *projectname_version = "x.y.z";An example combining all of these concepts would look something like this:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#define MAX_NAME_LENGTH 64
#define CONFIG_PATH_SIZE PATH_MAX
// Increment based on Software_versioning
// MAJOR (1.x.x)
// MINOR (x.2.x)
// PATCH (x.x.0)
// Dependent on work carried out during your revision
// https://en.wikipedia.org/wiki/Software_versioning
const char *projectname_version = "1.2.0";
typedef struct
{
char name[MAX_NAME_LENGTH];
char version[16];
} Package;
static int g_package_count = 0;
static void die(const char *msg)
{
perror(msg);
exit(EXIT_FAILURE);
}
static int load_package(Package *package, const char *name)
{
char config_path[CONFIG_PATH_SIZE];
if (!package || !name) return 1;
snprintf(config_path, sizeof(config_path), "/etc/packages/%s.conf", name);
snprintf(package->name, sizeof(package->name), "%s", name);
snprintf(package->version, sizeof(package->version), "1.0.0");
g_package_count++;
printf("Loaded: %s (%s)\n", package->name, package->version);
return 0;
}
int main(void)
{
Package package;
if (load_package(&package, "example") != 0) {
die("load_package");
}
if (!strcmp(package.name, "example")) {
printf("Package verified.\n");
}
return 0;
}So long as the core concepts and ideals of the style guide are followed; code in a DRY, and minimalist way - by sticking to standards, avoiding over-engineering, and handling system resources and errors responsibly, we ensure that the Vulpine code bases remain robust, transparent, and easily audit-able, simple. Follow these guidelines, sign your commits, build with intent, and we look forward to reviewing your pull requests on Codeberg or the Forge should you be invited.
Vulpine is a non-profit effort, founded by Charlie, and later Taylor under the BaronScott Consortium of two. Donations keep the servers online and fund development with the occasional round of coffee.
@vulpinelinux.org email address (after 182 days), and major direction voting rights.bc1qdv6hat8vs72geukaegrhrmc8x9nhvhxxcqyaqz0x2C8e7a5bAf8c135e7fC77Af93672AD59E29d18f4JEJNC22AZLSDW3JURPWBT3Z5DB5QHD7RLR7IKZRIOVASI7I4RMNBM2LLPA46vDaHiDwwr6mVCME1NwfUTeQMJCCkCWv4e9a84bUyKuTJwWjQs7BXrHP5AwcmcvqWFtoEHikEnuM5ajqTc9vrVGMPVLMeY(Bank-to-bank and international transfers in GBP/EUR are also available upon request via charlie [at] vulpinelinux.org).
You'll find an up-to-date way to start supporting the project on our website and home page.
Copyright 2026 © "Vulpine" by the BaronScott Consortium. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.