Note: Most of this FAQ was written in early 2019, and may not necessarily reflect the current state of the project.

Why?

I've just been frustrated with all the current offerings. I think for new users, it's important to have a quality Debian-based distribution whenever popular proprietary software tends to only officially offer .deb packages. The alternative is going through channels like the AUR on Arch and Manjaro, COPR/RPMFusion on Fedora/Mageia, etc. which not only can be daunting to people unfamiliar with the platform (particularly if they need to import someone's GPG key or fix a build failure), but can't keep up in terms of support or updates.

With that in mind, the state of Debian-based distros is awful right now. There's no good Debian-based rolling release offering. Except for Debian itself, which does include "testing" and "unstable", two effectively rolling branches tracking the latest changes to Debian. And these would be perfect, but Debian is pretty inaccessible.

Not including non-free firmware, while good for freedom advocates, means nothing to a new user except "My Wi-Fi doesn't work", and any modern AMD or NVIDIA GPU needs that firmware to function at all. I think the closest parallel you could draw is that Khromian is Kubuntu, except a rolling release. Among other changes from upstream. My goal is to create a sane, easy, rolling-release with a good KDE Plasma offering which acts as a one-size-fits-all, but especially as a sensible first choice for Windows power-users looking for an alternative.

I also think that rolling releases make more sense for new users. I've always ran into more issues doing major upgrades between fixed-point releases than tons of tiny incremental updates constantly. Plus, you're just generally less likely to run into issues with newer drivers and newer software. Debian Testing is a great middle-ground between stability and the cutting-edge since there's a set of criteria that has to be met before any upgrades to packages are pushed, including a mandatory waiting period for testing before being received by users.

systemd-boot? Why not GRUB like everyone else?

Khromian uses systemd-boot on EFI systems for a few reasons. For one, it's much simpler for the end-user to configure. The files are more human-readable, it automatically detects all OSes each time you boot (Useful for making sure Windows is always accessible in a dual-boot situation), and changes immediately take effect instead of requiring you to run update-grub afterwards.

It's also much easier to work with as a developer. The initial reason I switched was because of inexplicable issues with GRUB which didn't really explain themselves or give me any indication on how to fix it. On the other hand, systemd-boot announced configuration issues better, and ended up being much easier for me to work with.

However, there are drawbacks. Most notoriously, I'm currently forced to disable full disk encryption in the installer while waiting for upstream systemd-boot to support bootloader encryption. You can find more information on the interactions between LUKS and systemd-boot here.

Is there any reason to use this over Debian's own live images for the Testing branch that include non-free firmware?

Yes! Besides the fact that it's stupidly hard to find those images in Debian, I've tried to set mine up to be better out-of-the-box. The sources.list is set to "testing" in particular instead of just what the next stable branch will be, so it will roll indefinitely. I've also trimmed off a lot of the gunk from the default Debian KDE package, which is extremely bloated and messy. Also, the system is totally multi-arch by default, including both 64-bit and 32-bit graphics drivers, and a functioning Steam. Various config changes are made here and there to prioritize a normal desktop experience. Works well for a broad variety of use-cases. See the changes page linked in the above answer for everything.

How do I trust you?

You can't, but I've been involved with Debian (and Linux broadly) for a while, and I aim to be totally transparent about what I'm doing here. Again, keep in mind that after the install, my work is done. This is an installation image for Debian. I host no repos and cannot serve anything to your final system. Everything in your final system is stock Debian, save for any configuration changes or trivial scripts added as glue (like to update systemd-boot for new kernels).

As far as distro security and package transitions go, these are all handled by Debian, a project which has an incredibly strong track-record of security and stability.

Isn't this basically what Siduction does?

Siduction does similar things. I disagree with a lot of creative decisions they make, regarding default configuration, and they also host their own repositories rather than using Debian directly, which I further disagree with. The out-of-the-box experience between Khromian and Siduction is vast, as well as the target audience.

How can I contribute?

Thanks for reading down this far in the FAQ! Help is always appreciated.

Testing is the current Achilles' Heel. There are a lot of different possible setups out there, and I can't make it work for everybody with the limited hardware I have on hand.

If the installer doesn't work for you, please create an issue on the issue tracker containing your hardware details. This is whether you're installing on BIOS or EFI, the root filesystem you used, and, if the installer gave an error message, a photo or transcript of what it said.

Post-install, if you run into any expected but missing functionality, or any core feature that requires a workaround, please also report this to me and I'll see if it's possible for me to fix it in a way that'll prevent others from having to do the same.