Re: [opensuse-project] After the Richard talk... what's new for openSUSE
But I don't see Tumbleweed ever coping with proprietary blubs: moving target. The proprietary blubs always lag behind by several months.
Sad but true, but I also think people would do well to re-evaluate whether they really need the proprietary blobs - the open source drivers are getting better, and are a good choice for many people now. --
To tackle with this condition maybe we can decrease the update rate such that these proprietary blobs don't break. (This idea may seem ridiculous) Or We could decrease the rate of update of specific packages. For e.g. say Firefox doesn't affect the functionality of nvidia driver. So we can update Firefox as fast as we can. But faster kernel updates may break nvidia driver. So we link kernel updates with nvidia driver update. Then if a user has installed nvidia driver, he would get kernel update only if nvidia driver gets update or if someone has verified that given kernel update won't break the nvidia driver then also given kernel update can be pushed. Other users who don't have these proprietary blobs can get faster update. Note: I hate it when I get reply from opensuse-project+owner, that my mail is blocked and then I realize that I forgot to set text as plain text. And android's gmail app doesn't even have this feature. Regards Akash Vishwakarma (vish_99) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Le 02/05/2015 21:26, Akash Vishwakarma a écrit :
To tackle with this condition maybe we can decrease the update rate such that these proprietary blobs don't break. (This idea may seem ridiculous) we speak of tumbleweed, here, not an option :-)
jdd -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-02 21:28, jdd wrote:
Le 02/05/2015 21:26, Akash Vishwakarma a écrit :
To tackle with this condition maybe we can decrease the update rate such that these proprietary blobs don't break. (This idea may seem ridiculous) we speak of tumbleweed, here, not an option :-)
Right :-)
Note: I hate it when I get reply from opensuse-project+owner, that my mail is blocked and then I realize that I forgot to set text as plain text. And android's gmail app doesn't even have this feature.
Try K9. I think. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVFKt4ACgkQja8UbcUWM1wChQD/VEDNILY+KGhZWGxufqIrJ0/P qGifFWlPaUwwfemhU60A/i0bGT797+5fgJoyqI0Id2iaQMSYTo3Tc2Vp+UW0VYjZ =FmW5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sat, May 2, 2015 at 3:26 PM, Akash Vishwakarma
Note: I hate it when I get reply from opensuse-project+owner, that my mail is blocked and then I realize that I forgot to set text as plain text. And android's gmail app doesn't even have this feature.
Agreed. My android solution is to use K-9 as my email client. It works pretty well and has a text only option. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 2015-05-02 21:28, jdd wrote:
Le 02/05/2015 21:26, Akash Vishwakarma a écrit :
To tackle with this condition maybe we can decrease the update rate such that these proprietary blobs don't break. (This idea may seem ridiculous) we speak of tumbleweed, here, not an option :-)
Right :-)
Told you the first option seems ridiculous. But might not have read the second option. So, I'll post it again. We could decrease the rate of update of specific packages. Not all packages but of specific packages. For e.g. say Firefox doesn't affect the functionality of nvidia driver. So we can update Firefox as fast as we can. But faster kernel updates may break nvidia driver. So we link kernel updates with nvidia driver update. Then if a user has installed nvidia driver, he would get kernel update only if nvidia driver gets update or if someone has verified that given kernel update won't break the nvidia driver then also given kernel update can be pushed. Other users who don't have these proprietary blobs can get faster updates. -- Akash Vishwakarma -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Question Regarding the Proposed openSUSE (freeze - release) Distribution: When I think of distros made for stability, two distros come into my mind - Debian and CentOS Debian gets faster package updates than centOS but, Debian has slower package updates than current openSUSE. So, Richard, how fast package updates will be on proposed openSUSE Distribution. In your talk you told that the package update will decrease in comparison to current openSUSE distribution. In terms of package update frequency where will you place the proposed distribution with respect to the Debian and centOS. Faster than Debian or somewhere in between Debian and centOS or even slower than centOS. 3 year or more release cycle doesn't matters much to me. But, as normal conservative user what matters to me is package update frequency. Regards Akash Vishwakarma -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Akash Vishwakarma - 10:32 3.05.15 wrote:
Question Regarding the Proposed openSUSE (freeze - release) Distribution: When I think of distros made for stability, two distros come into my mind - Debian and CentOS Debian gets faster package updates than centOS but, Debian has slower package updates than current openSUSE.
So, Richard, how fast package updates will be on proposed openSUSE Distribution. In your talk you told that the package update will decrease in comparison to current openSUSE distribution. In terms of package update frequency where will you place the proposed distribution with respect to the Debian and centOS. Faster than Debian or somewhere in between Debian and centOS or even slower than centOS.
My guess would be something in between. Somewhere in this conversation coolo proposed to keep inner rings tied to SLE sources but as openSUSE is much bigger than SLE, I personally think that next openSUSE release could be something like a mix of SLE core and Backports project Ludwig spoke about (video upload pending) and maybe even more. But generally in the released products, we tend to try to keep same versions. If we tie core to SLE, we will also have quite small differences between 13.3 and 13.4 but at some point we will get a big jump when we will migrate to SLE13.
3 year or more release cycle doesn't matters much to me. But, as normal conservative user what matters to me is package update frequency.
Should be pretty safe - no big version updates, we have Tumbleweed for crazy guys like me :-) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
02.05.2015 22:26, Akash Vishwakarma пишет:
But I don't see Tumbleweed ever coping with proprietary blubs: moving target. The proprietary blubs always lag behind by several months.
Sad but true, but I also think people would do well to re-evaluate whether they really need the proprietary blobs - the open source drivers are getting better, and are a good choice for many people now. --
To tackle with this condition maybe we can decrease the update rate such that these proprietary blobs don't break. (This idea may seem ridiculous)
Or
We could decrease the rate of update of specific packages. For e.g. say Firefox doesn't affect the functionality of nvidia driver. So we can update Firefox as fast as we can. But faster kernel updates may break nvidia driver. So we link kernel updates with nvidia driver update. Then if a user has installed nvidia driver, he would get kernel update only if nvidia driver gets update or if someone has verified that given kernel update won't break the nvidia driver then also given kernel update can be pushed. Other users who don't have these proprietary blobs can get faster update.
I would suggest just to have two kernel branches for tumbleweed. The first one coming from http://kernel.opensuse.org/cgit/kernel-source/log/?h=stable as it does now. The second one is the latest longterm release. So, we would have 4.1.x and 3.18.y for user choice. And if user has issues with proprietary drivers then he just can stick on 3.18 or rollback. (It is similar to debian with kernel from backports) But, there are also drawbacks. I am not sure that OBS can handle this situation. And the most important: filesystem and other user-space stuff must be stay consistent between two kernel variants, so this will require extra efforts to keep the thing sorted out. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sun, May 03, 2015 at 12:04:50PM +0300, Matwey V. Kornilov wrote:
I would suggest just to have two kernel branches for tumbleweed. The first one coming from http://kernel.opensuse.org/cgit/kernel-source/log/?h=stable as it does now. The second one is the latest longterm release. So, we would have 4.1.x and 3.18.y for user choice. And if user has issues with proprietary drivers then he just can stick on 3.18 or rollback. (It is similar to debian with kernel from backports)
AFAICS (upstream) stable branches do not preserve kABI so that even if you follow, say, stable-3.18.y, you have no guarantee third-party binary modules won't break. Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sunday 2015-05-03 11:34, Michal Kubecek wrote:
On Sun, May 03, 2015 at 12:04:50PM +0300, Matwey V. Kornilov wrote:
I would suggest just to have two kernel branches for tumbleweed. The first one coming from http://kernel.opensuse.org/cgit/kernel-source/log/?h=stable as it does now. The second one is the latest longterm release. So, we would have 4.1.x and 3.18.y for user choice. And if user has issues with proprietary drivers then he just can stick on 3.18 or rollback. (It is similar to debian with kernel from backports)
AFAICS (upstream) stable branches do not preserve kABI so that even if you follow, say, stable-3.18.y, you have no guarantee third-party binary modules won't break.
No absolute guarantee, but a relative one. Given the influx of patches is lower, there is a good chance the API, sometimes ABI too, can stay the same. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
03.05.2015 12:34, Michal Kubecek пишет:
On Sun, May 03, 2015 at 12:04:50PM +0300, Matwey V. Kornilov wrote:
I would suggest just to have two kernel branches for tumbleweed. The first one coming from http://kernel.opensuse.org/cgit/kernel-source/log/?h=stable as it does now. The second one is the latest longterm release. So, we would have 4.1.x and 3.18.y for user choice. And if user has issues with proprietary drivers then he just can stick on 3.18 or rollback. (It is similar to debian with kernel from backports)
AFAICS (upstream) stable branches do not preserve kABI so that even if you follow, say, stable-3.18.y, you have no guarantee third-party binary modules won't break.
But this situation is tracked if third-party modules are built as RPM. So third-party RPM and kernel RPM are stay consistent. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sun, May 3, 2015 at 7:58 AM, Matwey V. Kornilov
03.05.2015 12:34, Michal Kubecek пишет:
On Sun, May 03, 2015 at 12:04:50PM +0300, Matwey V. Kornilov wrote:
I would suggest just to have two kernel branches for tumbleweed. The first one coming from http://kernel.opensuse.org/cgit/kernel-source/log/?h=stable as it does now. The second one is the latest longterm release. So, we would have 4.1.x and 3.18.y for user choice. And if user has issues with proprietary drivers then he just can stick on 3.18 or rollback. (It is similar to debian with kernel from backports)
AFAICS (upstream) stable branches do not preserve kABI so that even if you follow, say, stable-3.18.y, you have no guarantee third-party binary modules won't break.
But this situation is tracked if third-party modules are built as RPM. So third-party RPM and kernel RPM are stay consistent.
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I am wanting to see Evergreen continue whatever happens. I have several 13.1 installs I intend to convert to Evergreen. Steven -- ____________ Apply appropriate technology. Use what works without prejudice. Steven L Hess ARS KC6KGE DM05gd22 Owner Flex-1500 and Flex-3000 Flex-6300, FT-857D, FT-817ND openSUSE Linux 13.1 KDE Known as FlameBait and The Sock Puppet of Doom. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-03 05:13, Akash Vishwakarma wrote:
Told you the first option seems ridiculous. But might not have read the second option. So, I'll post it again.
We could decrease the rate of update of specific packages. Not all packages but of specific packages. For e.g. say Firefox doesn't affect the functionality of nvidia driver. So we can update Firefox as fast as we can. But faster kernel updates may break nvidia driver. So we link kernel updates with nvidia driver update. Then if a user has installed nvidia driver, he would get kernel update only if nvidia driver gets update or if someone has verified that given kernel update won't break the nvidia driver then also given kernel update can be pushed.
I still think it is not viable. And not really in the Tumbleweed spirit. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVGZnQACgkQja8UbcUWM1xqQQD9H+fynoj4s0rnF/EQ9r6unJiL zxE0t7JlUbaWr+UCnY0A/3epw7IpKUcE7GnzsYoxS/NheF4I5R+b2NNJ03ZOoxol =pOko -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
participants (10)
-
Akash Vishwakarma -
Carlos E. R. -
Carlos E. R. -
Greg Freemyer -
Jan Engelhardt -
jdd -
Matwey V. Kornilov -
Michal Hrusecky -
Michal Kubecek -
Steven Hess