Home_greyopenFATE - openSUSE feature tracking > #310773
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

differentiated cores performing optimal

Feature state

Rejected Information


A goal to boost openSUSE as a service to the world:

Deliver many optimal compiled openSUSE cores aiming to outperform any individualy (gentoo) compiled system!


icons/user_comment.png R. U. wrote: (3 years ago)

This should add a real vision in strategy discussions. We, as openSUSE, should aim a real ambitioned target:

Making a standardized openSUSE general core, ready to serve for many derivate distributions and for users heading for optimum.

icons/user_comment.png C. O. wrote: (3 years ago)

A program to set up a local osc instance and recompile any installed package + publish it to some local repository(also setup & configured for use)additionally handling updated packages would also solve this problem.

This would be a argument to get me using the stable openSuSE Version instead of Factory^^

icons/user_comment.png S. C. wrote: (3 years ago)

This is a motherhood statement if I ever I have heard one!

Christopher is correct in respect to a stable version!

The methodology of a new release being able to correct the current  versions bugs is not valid as the bug numbers of the current version are not fixed or closed. 

I would go bak to testing if for one moment I believed some action was taken on bug reports  - Testers, by and large offer their time freely and quietly know any bug report in YAST is a closed shop and it will never be fixed by a bug report.

In testing - If I believed that my accurate bugs were going to be actioned; I would start  testing again but the reality of this is Zero

Any others????

icons/user_comment.png B. W. wrote: (3 years ago)

Scott, over the past 15 months I have spent many hours testing during my spare time and reported some dozens of bugs, in YaST and other software delivered with openSUSE and the vast majority of those (especially all major, easily reproducible bugs) have been addressed.

As example you could take Bug #650966 from last week.

Also remember one of the strengths of opensource software: there is always the source so that you could (find someone to) fix it.

icons/user_comment.png A. J. wrote: (3 years ago)

Each of these versions need to be tested as well, put on the ftp server etc. This is a lot of work and experience has shown that only a few routines are really critical. I propose to instead concentrate on these routines and optimize them. Work in this direction is happening as we have e.g. two 32-bit x86 glibc versions and use the i686 if the hardware supports it. Also, glibc - the C library - is getting a couple of routines where at runtime the fastest implementation is choosen based on the actual cpu. We're also discussing in other thread libjpeg-turbo which does similar work. So, let's concentrate on those few places where it makes sense to optimize instead of creating a huge workload. I therefore reject this and welcome specific features on optimizing bottlenecks.

Last change: 3 years ago
Score: -3
  • Negative: 5
  • Neutral: 0
  • Positive: 2

No tags yet.

Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint