On Fri, 13 Mar 2020 at 10:21, sixpack13 <sixpac...@online.de> wrote: > On 13.03.20 08:20, Tim via users wrote: > ... > > > > While there's a point in your rebuttle, the reality is that not > > everybody waits. Those with the confidence or debugging skills do wade > > in, straight away. > > > > On the other hand, there are plenty of users without debugging skills, > > and there's little usefulness in them trying to help debug something > > when they don't know how. And risking bricking their computer just to > > be up-to-date doesn't do them any good, either. > > > > > > please read my comment again. > > my wording ended with "...in an VM or so" > > VM := virtual machine (gnome boxes, Virtualbox, etc.) > or so := a second install > > esp. for the VM: where is the risk ? >
VM's are very useful, but the virtual hardware doesn't cover the full range of physical hardware, so a VM can work fine when the same distro has a problem on the bare metal. In my experience, "user error" is the biggest risk factor for bare metal installs. Like "pilot error" in plane crashes, mistakes occur when the system provides inadequate information. Pilots, however, have seconds to choose how to react. Most installers provide an escape option before making an irreversible change, so "redo from start is possible", but if the user has chosen to install to a backup drive they may not get any warning that this might be a problem. Many problems could be avoided by simply disconnecting all external drives and non-essential devices when installing. Removing the current system drive and installing linux to a new drive makes irreversibel mistakes unlikely. > > and debugging skills: I too don't have them. > Beta testers don't need debugging skills, just the ability to generate good bug reports. I do have debugging in my skill set, but it is almost always better to report the bug and let upstream developers figure out the best way to handle the problem. Developers generally have a better overall view and know about changes in the pipeline that may dictate how a problem is best handled. > finding bugs by using Fedora Beta is enough - for the first part - > > nailing them done: you'll get enough help from *this* list, too > > everybody will win during finding, helping, debugging, fixing and esp. > learning (!!!) and in the end using a bug freeer release. > There are many different "mission critical" workflows that use linux. Production systems generally rely on long-term releases, but in some use cases long-term releases don't work and the required fixes are already available or can easily be introduced in Fedora. If the use case is sufficently important, a fix may be backported to the long-term release. -- George N. White III
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
