Every bug that exists in our tracker as of today
, will be resolved in the next 4 weeks
We're also going to be expanding our hosting soon (I'm actually just waiting on getting paid, which is when I was was
going to leave this announcement until..) to accommodate a lot more... :)
Once those 4 weeks are up, and obviously there's an ISO in between that too, we're going to begin work on Solus 2.0. Now obviously, we're going to continue to improve 1.0, make no doubt about that (And we're deliberately keeping the old X.Org to allow for AMD drivers, which are coming this week) - but we're going to start it all very very soon.
2.0 will in some ways be a different beast, but at the same time the same guiding principles. In short, it's an act of refinement.
There are some things that just will not be backported to 1.0, as it won't be technically feasible, but one of the first acts of 2.0 is to dramatically
slim the footprint of the core of the operating system.
Some small tidbits, and again, there are more announcements to come...:
* Solus 2.0 will be completely
stateless. And we'll start it out as completely stateless, in that it becomes a developer error
to ship anything non-stateless. Whassat mean? Go check out the +Clear Linux Project for Intel Architecture
documentation here: https://clearlinux.org/features/stateless
* The binary repository will be split into layers
, allowing separate domains of ownership. You'll have the very core
repository, which is the very heart of the distribution, and then separate profiles built up on top of this.
* The Core should have an absolutely minimal disk footprint. It is in fact this component which will be managed by our new (not yet published) toolchain-cruft successor. This will allow for hardware-specific optimisations.. which we'll go into at a later date.. :)
* The split will allow a merge-model for an atomic base used in our distribution media. i.e. Core+GNOME+Budgie
* For certain profiles, a fully atomic approach will be taken with separated apps. Right now we're evaluating limba. We feel it's a better fit for the project than the ostree approach. Long story short, these atomic profiles would not be using a package manager at all, so ostree isn't the answer here (There is more news to come in this field, stay tuned.)
* The split will enable SDK/OEM/End User separation. And now I say too much. :)
I could go on, but there are other things that I won't be announcing just yet
. Just enough to get your tongues wet, as it were.