Why does "newest release" not always mean "stable" for Hyperbola? And why comparisons don't help!
Hyperbola was, is and will be always oriented on long-term support resulting in a most stable system. For this goal (please refer on the packaging guidelines also) we explicit do not want to package always the newest releases of free, libre software-projects.
It is a common misconception that “newest release” should also mean “most stable” or “better system”. So if you think to complain that we just use from your current point of view quite too old packages, dependencies and / or applications, take our point also into your argumentation:
- We do not have interest in the “freshest software” we want working software resulting in a working system. Therefore we test also our packages at any time possible with care. And when something is working without errors and risks for security we see no reasoning to upgrade.
- We do not have interest in “newer is better” accepting also breaking dependencies. Broken packages, applications and libraries are in no situation acceptable for us.
- We want to motivate every user of Hyperbola to make usage of the testing-branch as Hyperbola is a community-work. So just don't compare Hyperbola only with others awaiting someone will solve it for you: If you miss something, try it yourself building, make proposals and share your insights. Hyperbola is not meant as system delivering on behalf of everyone demanding passive.
- We want a working, stable operating-system. Most designed for minimalism and oriented on the Unix philosophy, working always on democratic principles and inclusion for a colorful way of usage.
- We decline unstable software not releasing any stable sources and therefore we also decline to include more packages just for having them. All packages need maintenance afterwards and just to implement something half-way without a safe future working is never acceptable for us, may it be a service, driver, interface, library or any kind of application.
The essentials of Hyperbola's philosophy
Hyperbola follows therefore three simple but clear points:
- KISS: The shortform for Keep It Simple and Stupid means that all parts in Hyperbola's repositories and software is oriented on minimalism and strict reduced dependencies.
- DIY: The shortform for Do It Yourself means that Hyperbola has no interest to deliver and distribute all favorite packages. If users want some part software, they can surely port and package it on their own, sharing also the result for the community and get more feedback for improvals.
- DRY: The shortform for Don't Repeat Yourself means that we avoid maintenance many redundant dependencies within our system itself. This principle is a best practice in software development that recommends software engineers to do something once, and only once.
If all those points are not working for you, Hyperbola is not the system you should take into perspective for usage. We wish you therefore to find a better suiting system-base.
Hyperbola is an independent system, no fork from others. Therefore we also kindly ask not to compare Hyperbola with others in perspectives on offered software for example. Searching for problems and issues is a complete different point, but likewise the comparisons of other projects is most time complicated or not possible the same points also work for Hyperbola.
If you want to ask for help or want to make a stable oriented system better, please stop comparisons without giving a helping hand and work with us together. Also in regards of the documentation! We hope to motivate people bringing missed applications, libraries and more as ports to Hyperbola. Our operating-system and system-distribution can only be drawn together, so we mean exactly this wording. And let us test your packaging and ports to make an even better system!
Remember that this is meant as technical emancipation. So if you have barriers before you, speak up open and let's solve them.