Vulpine Linux

Vulpine as a group is an independent United Kingdom and Europe based software collaboration founded by Charlie, and later with Taylor under the BaronScott Consortium - a party of two.

Vulpine Linux is portable, micro-installable, persistent and transparent system thats defined as "terminal-first". Designed for standalone computing, micro-services, virtual environments and usable in micro, edge and embedded systems.

Overview

You'll find we've built a terminal-first Linux operating system around simplicity, transparency, and developer control, creating a system ("den") that can be understood end-to-end. With no AI (supporting our anti-AI policy), no agentic systems, or any out of the box bloat - unlike other systems.

Starting in a DOS-like initramfs-state system in 2025 by Charlie, with the intent to develop a modern minimalist environment that the end-user wholly owns using a reduced flag kernel, boasting minimal modules. The operating system today still embraces minimalism, but with systems and packages in place for programming, reproducible development (supporting Docker), custom tools (CVSH, VPM), having a mostly package-driven customisation base; allowing users to shape their own environment ("den") instead of having one imposed during installation. Keeping to the minimal, transparent and privacy first ideals it began with in early 2025.

In an increasingly connected and security-conscious world, lightweight and modular operating systems are crucial for a range of applications and end-users. Vulpine Linux embodies this philosophy; by which we aspire to develop a minimal Linux-based system, optimised for USB boot-ability and persistent storage. From there you decide how your system, your "den" unfolds. Built, shaped, and expanded on your terms - we offer monthly releases (indev) at this time - in which you can take in your own direction through our package manager, or by compiling your own binaries!

Our goal is simply this; build a functional, minimal, environment with optional expansion. That way the system remains understandable from end-to-file-system-end allowing you to self-service with greater ease, ensuring self-served security and ensuring privacy whilst allowing for us to maintain it easily.

Getting Started

You can either download a monthly build from our website here, or you can self-build the repository from our origin using this simple command:

git clone https://forge.dnsrail.org/vulpinelinux/vulpinelinux.git --depth 1 && cd vulpinelinux/

If you plan to fork-and-contribute (following our wiki guide) you'll be best off forking our codeberg mirror remembering to sync between Vulpine Linux releases to ensure you're always contributing on the latest version. This is explained later under "Contributing" on the wiki.

Either way, once you've pulled from the origin or your codeberg fork, you'll have the public open source for Vulpine Linux - congratulations. From here you can self-compile with ./build.sh, where you'll be left with a .iso and .qcow2 file ready for booting into with QEMU, migrating to your chosen virtualisation software or installing onto your hardware, typically a server.

Build Requirements

Warning

This script assembles the system but does not build the kernel or userspace automatically. This is because our bzImage (kernel) is already provided, and custom userspace binaries are already placed into rootfs, this all you need to get started.

The build script assumes the following tools are installed:

• Linux environment (or WSL on Windows)
• cpio
• gzip
• grub-mkrescue (grub2)
• xorriso

As a reminder, the Linux kernel (bzImage) is already compiled and present in: ./linux/arch/x86_64/boot/bzImage - you will be expected to build around this.

After building you can launch it using QEMU while being in the vulpinelinux directory.

qemu-system-x86_64 \
  -m 1536M \
  -smp 4 \
  -drive file=vulpine-linux.qcow2,format=qcow2,if=virtio \
  -cdrom vulpine-linux.iso \
  -boot d \
  -display gtk \
  -vga virtio \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 \
  -device virtio-net-pci,netdev=net0

Right now there is only one account that exist out-of-the-box: root:root this is your generic root and sudo user.

Once in the system you'll be in a live-boot media, to have persistence and full-installation follow these steps:

• Launch the QEMU command provided above.
• Run ../installvulpine.sh
• You'll be prompted for a drive from the list /dev/vda for example.
• Follow any on-screen prompts, once finished you'll be told to shutdown the machine.
• Relaunch with the following:

qemu-system-x86_64 \
  -m 1536M \
  -smp 4 \
  -drive file=vulpine-linux.qcow2,format=qcow2,if=virtio \
  -boot d \
  -display gtk \
  -vga virtio \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 \
  -device virtio-net-pci,netdev=net0

This will then be your full-system installation with true persistence.

Contributing

We strongly encourage users looking to contribute to follow our wiki as it outlines expectations, code style guide, and the process in its entirety but you can read the broad expectations below...

Anti-AI Clause

Firstly the project adopts a strict stance against artificial intelligence integration, aligning with the principles outlined by NotByAI and Linus Torvalds’ pragmatic approach that declares the human responsibility element:

"You, the human submitter, bear full responsibility and accountability for reviewing the AI-generated code, ensuring license compliance, and for any bugs or security flaws that arise."

Contributions must be human-led, reviewed, and understood by the submitter.

Code that cannot be clearly explained, maintained, or trusted will not be accepted. Low-quality or unverified contributions will be rejected (sign your commits - there is no excuse in 2026 not to sign) the user ideally should match your signature but the main part is signing and verifying.

We want Vulpine Linux as a system, and a distribution point for open-source code, to be human-first. This will ring true for contributions made across the scope of the Vulpine Group, wherever possible we will support human-first.

How to Contribute

We want to start by saying thank you for considering a contribution that aligns with Vulpine Linux's philosophy, whilst we encourage people to follow the wiki, we know you often want a fast answer. This is a low-level, from-scratch system - so contributions should reflect an understanding of how the system is built and why it is built in this way.

As such, we kindly ask that you focus on one-branch per feature or fix, and do that single branch feature-or-fix well. This way we can ensure proper-steady and audit-able contributions rather than monolithic merge requests that risk going against the philosophy we aspire for.

1. Fork and Clone

Fork the repository and clone it locally:

git clone https://codeberg.org/YOUR-USERNAME/vulpinelinux.git && cd vulpinelinux/

Warning

Commits made to the main repository will be rejected, you have been warned - this is reserved for core, high-priority pushes only from the core Vulpine Group, the branches on main are then deleted post-merge. All commits must be done through forking and via Codeberg unless you're one of the core Vulpine Linux maintainers.

2. Making Your Changes

Before making changes, create a new branch.

If its a feature (such as adding, updating or changing an existing software) git checkout -b feature/your-feature-name

An example would be: git checkout -b feature/csh-config

If your goal is to work on an issue you should use git checkout -b fix/issue-reference-name

An example would be git checkout -b fix/expand-alias-overflow

Your changes must be made in a dedicated branch (e.g. feature/your-feature-name)

Work within the existing structure:

• rootfs/ - userspace (init, shell, configs).
• busybox/ - system utilities (omitted at this time, this is a reference).
• linux/ - kernel source (where you'll find bzImage).
• build.sh - runs the full build including compiling GRUB, etc.

Examples of valid contributions:

• Improvements to build.sh
• Statically compiled tool updates.
• Kernel or otherwise config optimisations.
• Networking or system stability fixes.
• Contributions towards the stable-release expectations inline with the phased approach.
• Documentation improvements, these must be British-English.

3. Follow Project Constraints

• All binaries must work in the minimal initramfs environment (this is the QEMU boot-media environment).
• We prefer static builds where possible, otherwise supply the dynamic libraries and during Pull Request list ones provided.
• Avoid unnecessary dependencies (especially glibc-heavy ones)
• Keep the system lightweight and understandable - our wiki explains it here.
• Meet "Pull Request Expectations".

4. Test Your Changes

Rebuild and test:

./build.sh

Run in QEMU:

qemu-system-x86_64 \
  -m 1536M \
  -smp 4 \
  -drive file=vulpine-linux.qcow2,format=qcow2,if=virtio \
  -cdrom vulpine-linux.iso \
  -boot d \
  -display gtk \
  -vga virtio \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 \
  -device virtio-net-pci,netdev=net0

Follow the flowchart as a general guide:

flowchart LR
    A[Build-and-boot] --> B{Is your implementation working properly?}
    B -->|Yes| C[Great, take a screenshot and write documentation]
    B -->|No| D[Debug and try again]
    C --> E[Push to fork, pull request, supply docs, submit]
    D --> B

Ensure:

• System boots cleanly
• No kernel panics
• Your feature works as intended
• You haven't inadvertently broken something else
• It can be built reliably time-again using ./build.sh

Avoid hard coding anything that risks being re-written by ./build.sh notably GRUB.

Warning

Dynamically linked binaries will not work unless all required libraries are included, you are responsible for having tested your commit works via the previous steps!

5. Pull Request Expectations

• You've made the feature in git checkout -b feature/your-feature-name or similarly if its an issue or fix as issue/* or fix/* on your own fork, not on the main repository.

• You must detail in at least one paragraph (short if you prefer) what your submission is resolving; describe what you changed and why, and how your code functions cleanly. You can keep it simple, but it must be understandable.

If we do not believe you wrote it, or understand it for yourself - it will be rejected.

• Include any relevant logs or screenshots if applicable for documentation purposes.

• Where possible include a reference link or documentation, so that others can learn from you and the project.

"Using auto-ai to make submissions, pushing clearly AI-generated code, repeated low-quality or unreviewed submissions may result in restricted contribution access. We are a human-first endeavour, we understand AI can be found in the IDE through to documentation in real-life and we cannot stop this but the more we minimise it here, in our project, the happier we all are." ~Charlie

You can then push your branch to your fork and open a Pull Request against the main repository ensuring your PR description follows the expectations outlined above, remembering to sign your commit we will reject any that are not signed.

Bare in mind when providing a -m for messaging to keep it short-and-simple for example git commit -m "patch for fixing {issue}", no one wants clunky and excessive messages, we will reject ridiculous or over-wordy messages.

Review Process

All contributions are:

• Reviewed manually
• Tested for stability and compatibility
• Evaluated for alignment with project philosophy

Submissions that cannot be clearly explained or maintained will be rejected. This is true for unsigned commits or those submitted on/to the main repository - it must go through your fork, and Pull Requested. We cannot overstate enough that Vulpine Linux is built step-by-step with intent so contributions should reflect that same mindset and set the bar for other developers to come after. We appreciate strongly well written and proper commits - it matters massively for reference and professionalism both on your part and ours.

Support

For support, you can reach out on Discord, or InTheMansion irc channels #lobby, or #vulpinelinux.

We strongly suggest reading our wiki before submitting any issues, or checking Discord first, because not everyone has Codeberg and issues might already be known before you open one, it is always worth checking in with the community first.

License

We have applied for a Linux sublicense from the Linux Foundation. The use of the term "Linux" in our domain name and project references is intended solely to indicate that we are a Linux-based distribution. It should not be misconstrued to imply official endorsement, or that a trademark license has been formally granted at this time. The Vulpine Group is the development group behind the Vulpine Linux operating system and the Vulpine software suite.

Vulpine Group and their Linux-based OS 2026 by BaronScott Consortium is licensed under:

Creative Commons Attribution-ShareAlike 4.0 International

This also applies to Vulpine Group developed software, the Linux-based operating system and is not intended to supersede licensing applied to tools our our software is dependent upon nor Linux itself. All original licenses apply where ours cannot apply.

This license requires that reusers (you) give credit to the creator (us). It allows reusers (you) to distribute, remix, adapt, and build upon the material in any medium or format, even for commercial purposes. If others remix, adapt, or build upon the material, they (you) must license the modified material under identical terms.

• Credit must be given to us, the creators
• Adaptations must be shared under the same terms

As mentioned this is not intended to supersede existing licenses and you must comply with their licenses in addition.

How do you give credit?

This can be given clearly on your website, or beside the downloads or a repository-fork. So long as it apparent in some reasonable - but fair - fashion that you've distributed, remixed, adapted, and/or built upon Vulpine Groups Linux-based distro.