On Fri, 13 Mar 2020 at 10:21, sixpack13 <sixpack13@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
