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.

Most important we also have no interest in always stating what we “dislike” instead of doing what we really like: This is community-oriented, free and libre software itself. We want to build, offer and use an operating-system dedicated to user-freedom. Sure, we also criticize direct or indirect development in general and detail, but we do not want to end in cynicism and hatred. With this repeating also fallacies and copy them, instead of doing a complete different paradigm.

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.

What about "guidance" and "support" for people?

Yes, guidance is always an important concept for us. But this only works out positive when both sides are really engaged. So for sure we want to guide, support and offer mentorship. But when we see that the person awaits full-time support, meaning to get only said everything and repeat without learning and questioning, this concept is breaking immediately. At that point we stop the mentorship also and won't go on with it in the current case.

We think that it is not too much to bother and experiment individual with the own system, developing, changing and surely also experiencing problems. If there is no interest to do exactly this, there is also no real interest within Hyperbola as a system from our point of view.

What about inclusion of binary packages?

We reject any binary-only packaging. That means we will never accept packages offered only in binary form or based on binary releases done. Hyperbola was, is and will always be a source-based operating-system.

Conclusion

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.