Version 2017.04.18.0 Release Date: April 18, 2017 (Release Notes)
NOTE: This distro comes on a DVD. Please ensure that your system will read from a 16x DVD before ordering.
So let’s get the killer buzzwords out of the way first. Solus is a desktop-orientated, modern Linux-based operating system with a focus on user-friendliness. Now, that sounds incredibly dull and generic, and describes several hundred projects. So let’s go a little bit more in depth here.
One desktop to rule them all.
Solus is built specifically for a single vertical. We know you can download other desktop orientated projects. Truth is, every package, every tweak, configuration and optimisation, is intended (and designed) solely for desktop usage. So if you’re thinking about running a Solus server, forget about it. Our repository consists of a tightly integrated set of packages, designed to deliver a singular, cohesive experience. We don’t need to patch or work around the work of others, we deliver one well designed unit to our end users.
It gets out of your way
If you’re looking for an operating system were you are constantly nagged and prompted to change this, add that, edit this thing and unbreak the other, you’re looking in the wrong place. Solus just works, and keeps on Just Working. After all, we’re building this system, it should know what to do, right? Enjoy an unobstructed computing experience, and just get on with it. Lucky for you, it’s a beautiful, yet uncluttered desktop, so it’s also very enjoyable to use.
Wait, this is a good thing? Sure is. We don’t ship multiple kernel packages. We don’t ship multiple toolchain versions. We ship what is used to build the current Solus version. This ensures there aren’t hundreds of untested configurations, the default shipped Solus will always work and update as intended, and advertised.
Packaging is a build tool
First in our list of controversies. We don’t care about “strong package management features”. We look at packaging as a method for building logical units of code, and sending them to the user. Therefore, it is a build tool. We’ll re-touch on this topic later in the development section.
While we’d love to live in a world where everything was completely libre, for our userbase this isn’t always possible. So we do make it easier to install proprietary GPU drivers, or network drivers. We also ship codecs in our default OS images, to ensure that Solus is ready to use from the get-go: whether its utilising the hardware you have correctly, or enabling your multimedia/home life.
We’re very much in touch with our community. On multiple occasions, we’ve walked through hardware issues with our users in real time, and deployed a kernel update to them inside of 15 minutes, getting that pesky touchpad working. We encourage and welcome contributions, and at the end of the day, we’re all doing this for each other. So, what benefits you, benefits us.
Optimised for the desktop. No, seriously.
We raise eyebrows with this quite frequently. We spend a lot of time optimising Solus to run better, faster, and more efficiently, on the hardware available to our users. Quite famously, we had an Intel NUC booting in 1.089s, using only 178MB of RAM idle on boot. We spend time working heavily on the toolchain, validating binary performance to ensure that you get the best possible experience for the desktop. We spend a significant amount of time on our kernel too, and ensure we have the best working configuration for our users.
Many of our core libraries have been aggressively optimised, and we’ve spent a lot of time creating a level of integration and performance that wouldn’t be possible in a derived distribution. Whether you’re working or playing, Solus screams along on your desktop.
Solus is completely independent
It’s built from scratch, therefore has no parent project. Sure, this means it’s incompatible with rpm and deb. But it also means it’s completely free of external influence, policy, and companies/organisations pushing their own agenda. We’re free to call the shots, control all the gates, and ensure a single integrated experience. Combined with our focus on autonomy (and a waterfall development model) we can push security updates and bugfixes to our users in the shortest possible timeframe. We’re also free to compile our source code how we see fit, tying in with our own optimisations and security changes.
Now we’ve got some of that out of the way, let’s touch upon some of the differences in approach we have when it comes to development
Autonomy is king
As we’ve said before, we view packaging as a build tool. As such, we have systems and scripts in place to ensure we spend the absolute minimum time required to deliver this package. In fact our packaging format automatically decides on subpackages, and how to split these (such as pkgconfig files, versioned .so’s, gtk-doc, etc)
Updating a package can be as simple as a “make bump”, and producing the latest ISO consisting merely of a “make” command. You (the maintainer) need to push your changes to unstable for testing? “make publish”. Get real time feedback from other developers and your package consumers, stabilise it and we’ll get it down the waterfall.
We integrate many workflows and practices into very simple workflows, such that all maintainers can simply “make cvecheck” their package to consult the NVD DB for the latest non-embargoed CVEs.
Stringent package rules, but not for you to decide..
With our tooling and packaging approach, you set the upstream/source name of a package. The subpackage names are fixed suffix modifiers, leading to highly consistent package naming, which isn’t for the developer to decide. You can of course correct the file placement through mappings, but this process leads to a far faster development process. So that “vte” package now becomes “vte”, “vte-devel” and “vte-docs”. Your next project uses “pkgconfig(vte)” as a build dependency, and the dependency graph itself is self resolving through automatic pkgconfig and binary dependencies throughout the repository.
Thou shalt not conflict
We’re here to deliver a single experience. So we don’t need 3 different provides of “libjpeg.so”. We ensure in all cases (unless absolutely unavoidable, like a proprietary GPU driver) that we do not have package conflicts. Packages will only work in a single combination in our repository, and we won’t have multiple pkgconfig providers. This leads to a cleaner and better designed software repository. So you won’t ever get into a situation where one provider conflicts with another, and you have a broken update path. In fact, it’s impossible in Solus. We only keep packages while they’re useful.
Feature development is time well spent
The more we automate in terms of packaging, and daily maintenance tasks, the more time we actually have to spend on the things that matter to you, through feature development. By taking what at one point could have taken several hours, down to 3-4 minutes for a new package, we free up our hands to work on the cool stuff. Like our upcoming backup management, the driver management UI, system snapshots, etc.
And lastly, we couldn’t have a why-solus page without answering these two..
Why not base on <insert distro here>? They’re Way Rad.
In a nutshell, (and assuming you’ve read all the points up to here) we don’t believe any other project meets all of these points, and still has the same progressive views on how to build operating systems, deploy them, engage with their userbase, while retaining the deliverables, quality and forward-looking attitude we have. Solus is a one-of-a-kind, and that’s why it’s here. If it had been done already, we wouldn’t need to exist.
But you could put Budgie on any distro!
Yes, we could. However, Budgie was built for the Solus Project, not the other way around. It’s one element of a complex equation, which is delivered as the Solus Operating System. It’s a necessary part of a wider vision, and is simply the front-end to everything else we do. Or to put it mildly ironically, it provides the windows to our world.
|Country of Manufacture||United States|
|Disk Type||Live Disk|