KaOS; A lean KDE Distribution
The idea behind KaOS is to create a tightly integrated rolling and transparent distribution for the modern desktop, build from scratch with a very specific focus. Focus on one DE (KDE), one toolkit (Qt), one architecture (x86_64) plus a focus on evaluating and selecting the most suitable tools and applications. All work is geared toward packaging, not developing new tools or applications.
There is no goal to make the most possible software available, KaOS will stay limited in size of the repositories, and will work on quality instead of quantity. That goal makes it clear, a large user base is not what is intended or expected.
Moving away from proprietary Operating Systems to open source options (Linux-based, BSD based, Solaris based) is about wanting freedom and choice in almost all cases. But should any such Operating System or Distribution not make some choices of what it believes is the best fit? KaOS sees a lack of focus in that respect. To create the highest quality Distribution possible, there needs to be a focus to make sure the user gets the best possible for whatever choice they made.
It simply is not possible to package any and all to work perfect for every Desktop Environment or Toolkit.
KaOS has made the choice to use the Linux kernel as a base (though the Illumos kernel is under constant evaluation, and a future switch is a wish). After that choice, the best available package manager, most flexible way of package building, repository maintenance is pacman/makepkg for a rolling distro like KaOS.
As for the Desktop Environment, there will never be a change, whether it is Linux or Illumos based, KDE will be the choice, Qt the Toolkit.
With those choices in place, April 2013 package building for this independent distribution was started. KaOS is a build from scratch distribution, every package in every repository is build by and for KaOS. By July 2013 the initial goal of about 1500 packages was reached.
Making the choice for KDE/QT does not mean KaOS loses sight of the importance of having the best tool available for the job. Most of the time it is believed KDE/Qt provides the superior tool, but there are a few applications were the GTK option is the only available of that kind (Inkscape, Ardour to name two), or in the case of web-browsers for example, the Qt options do not stack up to their GTK counterparts. For those instances, GTK applications are available, though their number will stay limited.
The repository layout is simple, and consists of three groups, Core, Main and Apps. A regular complete system update will always give you the latest available, without the need for any re-install of the system.
“Core” has the base packages needed for a system to boot-up, communicate with the BIOS connect most hardware and set basic shell options. Example packages are the kernel, systemd, toolchain for building and basic command-line tools. This repository is carefully rolling, since any upstream update not thoroughly tested greatly affects the stability of the system.
“Main” repository consists of all the needed libraries, extra drivers and firmware needed to make the Desktop and Applications function. Many of these can be fully rolling and will move to the end-user after a seven to ten days testing period. Some more vulnerable packages will enter after enough upstream feedback is available that no regressions have occurred.
“Apps” consists of all packages seen and used by the users, including KDE and any needed tools. It is fully rolling and you can expect updates to reach this repository after a short testing period, unless it needed to be built on newer versions of Core or Main packages, than it will have to wait until those are ready to come out of their testing period.
“Build” is were all packages start, whether it is a rebuild, update or new addition, all goes to build, once gone through the proper testing, than they are moved to their respective repository.