CarcinOS logo

About CarcinOS

CarcinOS is a Linux-based software distribution focused on simplicity and stability. Above all else note that CarcinOS is still early in development, and may not be stable or usable for many use cases. That being said, CarcinOS is being used right now to serve you this page.

Why use CarcinOS

There are many, many Linux and BSD software distributions available; there's no need for more generic distributions. CarcinOS, however, possesses a number of features which make it suitable for a number of special cases, such as use on servers and embedded machines. Some of CarcinOS' features include:

Some additional, albeit obscure, reasons to use CarcinOS include:

Downloads (x86_64)

Base system (TAR)
Base system (CPIO)
Prebuilt Linux kernel
Prebuilt Linux kernel for one-file boot
Bootable CarcinOS disk image (UEFI only)

The default login name is 'root' and the default password is 'test'.

If you want the easiest possible way to check out CarcinOS in a QEMU virtual machine, download the one-file boot image and run 'qemu-system-x86_64 -m 1G -kernel carcinos-onefile-vmlinuz'. If you want the easiest possible way to check out CarcinOS on a UEFI system (basically all modern PCs), download the bootable disk image. Both of these images will not write anything to disk by default, so they will not overwrite existing installations, and any changes you make will be lost once the system is rebooted.

To create a full CarcinOS installation, simply extract the base system (preferably the TAR archive) to an empty filesystem which supports UNIX file modes (preferably ext4). Then, set up a bootloader that will start a Linux kernel with this new filesystem as its root. If you don't understand these instructions, you probably don't want to create a full CarcinOS installation.

Repository mirrors

In order to keep packages up to date, it is important to regularly replace /var/db/parcel/repo/ with the below archives. These provide descriptions about binary packages, allowing the package manager to install and update packages. It is completely safe to delete /var/db/parcel/repo/, as it can be recreated at any time using the below archives. Do not under any circumstances delete or tamper with /var/db/parcel/installed/, though.

It is important that you only download this archive over a TLS-secured connection.

Binary package mirrors

When installing and updating packages, the package manager will need to download the needed binary packages from a remote server. They can be fetched using any of the below links, or alternatively you can manually ensure that the needed binary packages are present in /var/cache/parcel/.

It is important that you only download these archives over a TLS-secured connection.

Common FAQ

Is CarcinOS free?

Yes! All components of CarcinOS are freely distributed under an open source license. For more legal information about any component, see the license agreement attached to that component.

For legal reasons, CarcinOS cannot distribute any packages containing proprietary software; the user must install these on their own. CarcinOS documentation does provide instructions for installing certain proprietary packages which may be required for the system to function, such as device firmware.

What architectures are supported by CarcinOS?

The official CarcinOS binary package repositories (currently) only support x86_64. That being said, the CarcinOS build system has easy cross-compilation support, and should allow a system to be built for almost any architecture. In particular, if you attempt a build for x86 or ARM, please let us know, we'd love to hear about it!

The first milestone of CarcinOS development has been focused on server use, so there is very little desktop software present in the package repository at the moment. In the future, more work will be done to support desktop systems.

Minimum boot requirements for CarcinOS are:

What devices are supported by CarcinOS?

In theory, any device supported by the Linux kernel. In practice, CarcinOS currently only has a limited set of packages mainly targeted at console and server usage. As a result, a lot of devices, such as graphics and sound cards, aren't really usable simply due to the lack of applications that can use them. As more packages are ported to the system, this will become less and less of an issue.

Do note that the Linux kernel build shipped with CarcinOS images is intentionally kept very minimal, and is compiled without support for many devices as a result. There is a high probability that you will need to compile your own kernel to enable certain features, such as device-specific network drivers. If this sounds like a daunting task to you, then you should probably hold off on CarcinOS for now.

Is CarcinOS production ready?

Absolutely not. CarcinOS is still early in development. Great care is being taken to ensure it's as usable and stable as possible, but nevertheless there are likely to be bugs. Feel free to use CarcinOS, but keep in mind that it's new software and will likely need a little extra attention to keep in top shape.

Technical FAQ

These are questions with very technical answers, which are interesting only to computer nerds. If you just want to try out CarcinOS, there's no need to read this.

How does CarcinOS Bundler work?

The "base system" is the set of files and directories constituting all of the programs and configurations provided in the stock, unmodified form of the system (ie, as the system would appear after being freshly installed). In the case of CarcinOS, the base system takes the form of an XZ-compressed CPIO archive.

CarcinOS Bundler is a small and straightforward program which allows combining multiple archives into a single base system. Generally, this involves merging TAR archives which contain files for specific packages. As package management is a non-trivial task, CarcinOS Bundler has a built-in wizard to aid the user in deciding which packages they need, so that a suitable base system can be produced.

In addition to pre-made packages, CarcinOS can also make use of your own custom changes. This allows the creation of a custom base system which is already pre-configured and ready to go, allowing systems to be installed or updated with zero additional configuration by simply replacing the previous base system with the new one. This is excellent for cases where you want to replicate the same system across many devices.

A base system produced with CarcinOS Bundler can be installed and booted by either extracting its contents as-is to an empty filesystem (which becomes the root filesystem for your new system), or mounting it directly as an initramfs (see "How does one-file/two-file boot work" below).

How does one-file/two-file boot work?

During startup of a Linux system, the kernel can either mount a filesystem from a disk (specified with the 'root=' or sometimes 'initrd=' options), or mount an 'initramfs' (specified with 'initrd='), which is expected to contain a root filesystem suitable for continuing the boot process.

Typically, the initramfs is very small and only contains the bare essentials needed to mount the real root filesystem (although CarcinOS does not require this; CarcinOS is capable of booting without an initramfs, so long as the configuration is supported). CarcinOS takes this a step further though, allowing the entire base system to be stored in the initramfs.

The result is that the only files required to boot are /vmlinuz, which contains the Linux kernel itself, and /initramfs.cpio.xz, which contains the base system. The /vmlinuz and /initramfs.cpio.xz files should be located on an EFI system partition, allowing the machine's UEFI firmware to boot the Linux kernel. An EFI entry will likely need to be set up in order to tell the kernel the path to the initramfs (eg, 'initrd=initramfs.cpio.xz').

One-file boot is very similar to two-file boot, with one difference: The initramfs containing the base system is built directly into the Linux kernel at compile time.

This means that the only file necessary to boot is /vmlinuz. Although this is convenient, the main downside of one-file boot is that it requires recompiling /vmlinuz every time the base system is updated. For this reason, two-file boot is generally preferable, although one-file boot may be suitable for things use in systems such as "rescue disks", which do not receive updates and benefit from the added simplicity.

Note that since the initramfs is read-only, an external filesystem is still required for the purpose of storing newly written files. This means that unless the system is entirely read-only and is not intended to retain any data across reboots, an additional filesystem will be required. This is why it's referred to as "two-file boot", rather than a "two-file system".


Here's some wallpapers, in case you're into that.