Fedora Lifecycles: imagine longer-term possibilities!

lifecycle
schedule
fedora-30

#21

@mattdm: The Fedora LTS version is a good idea regarding the kernel (long-term), when a user of a Fedora flavour can choice a kernel with long-term-support. For older hardware it is often sufficient enough to run with a older long-term-support kernel. On the other hand a LTS version will bind manpower to maintain a LTS version. All other amazing things like actual software etc. should remain. A rolling release I would only offer, if a high-quality testing team is available, otherwise it would be a disaster for many user when they get a broken system and they have no help from Linux-professionals. Today I would wish to have an automatic system-upgrade every release-point with a self-maintaining OS supported by Artificial Intelligence in the background to avoid obsolete packages and digital “waste” caused by updates and other user/system activities. This options should be standard on all Fedora systems to guarantee a smooth running and well performing system. The software install options should prevent that a user can do system-destroying actions. That is my vision of things that are usefully and realisable and do not destroy the spirit of Fedora being a cutting-edge and always modern OS. For Microsoft Windows there are also plans to build a self-repairing and maintaining system. I am sure, that this will broaden the user-base of Fedora. I hope my ideas will have practial effects for Fedora.


#22

@mattdm: The Fedora LTS version is a good idea regarding the kernel
(long-term), when a user of a Fedora flavour can choice a kernel with
long-term-support. For older hardware it is often sufficient enough to run
with a older long-term-support kernel. On the other hand a LTS version will
bind manpower to maintain a LTS version. All other amazing things like
actual software etc. should remain. A rolling release I would only offer,
if a high-quality testing team is available, otherwise it would be a
disaster for many user when they get a broken system and they have no help
from Linux-professionals. Today I would wish to have an automatic
system-upgrade every release-point with a self-maintaining OS supported by
Artificial Intelligence in the background to avoid obsolete packages and
digital “waste” caused by updates and other user/system activities. This
options should be standard on all Fedora systems to guarantee a smooth
running and well performing system. The software install options should
prevent that a user can do system-destroying actions. That is my vision of
things that are usefully and realisable and do not destroy the spirit of
Fedora being a cutting-edge and always modern OS. For Microsoft Windows
there are also plans to build a self-repairing and maintaining system. I
am sure, that this will broaden the user-base of Fedora. I hope my ideas
will have practial effects for Fedora.


[Visit
Topic](https://discussion.fedoraproject.org/t/fedora-lifecycles-imagine-lon
ger-term-possibilities/690/21) or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click
here](https://discussion.fedoraproject.org/email/unsubscribe/f04a4d09d4cebe
037de4025a53dbe9d6f1b79866ffd4ddc119b3dcc1addc315b).

What problems would the use of an old kernel solve? I have systems from 2004
that run Fedora 29 today. The only systems I use a different kernel on are my
own X200 tablet and T400 laptop, but even then it’s only because I put my
kernel in cbfs on those.

Why have all of the wasted effort for a LTS kernel?

The software install options should prevent that a user can do system-
destroying actions.

Of course, and dnf does that already. You’d have to be trying to break your
system, if you’re using only the package manager.


#23

I believe the usual idea is that kernel upgrades can break things, which is relatively rare but pretty bad when it does happen, and in certain uses/workflows you can’t really afford that risk.


#24

If that were true, then those updates should be tested before mass applied.
Even if we did have a LTS kernel, there’s no way we could test literally all
hardware which would be affected by a given change.


#25

Well, yeah, but the chances of something breaking due to a ton of changes in drivers, filesystems, and system internals are a lot higher than three backported security buffer overflow fixed.