dnf versus yum

[Chris Murphy]

On Jan 6, 2014, at 12:38 PM, Stephen John Smoogen <smooge at gmail.com> wrote:

> 
> 
> 
> On 5 January 2014 18:12, Chris Adams <linux at cmadams.net> wrote:
> > the ordianry user - i doubt
> 
> The "ordinary user" won't do "yum erase kernel" either, so that's moot.
> The rescue kernel is another option, right there on the boot menu; if
> you actually removed all running kernels, it would be the _only_ Fedora
> option (and the only option at all on a system without multiple OSes
> installed, so booted by default).
> 
> 
> Law of Out of Date Technical Support:
> 
> If an expert says "no ordinary user" would ever do a command, they have not worked front line Tech Support recently enough.

Sure. But I don't know how much hand holding with the CLI is practical and necessary. I can't tell you how many times I've done wipefs -a /dev/sdb, when I meant wipefs -a /dev/sdc because the f'n node ordering changed the drives around. I don't expect to be hand held through that, I mean what could even be done?

mkfs.xfs has had (and mkfs.btrfs now also has) a -f flag that's required to format over an existing volume. That's saved me a few times. However, now that I'm used to it, I bet it won't anymore because I'm already just including -f as second nature. *shrug*

Since "* remove kernel" appears to be inspecific, removing all kernels isn't what I'd expect. It's not how mv or cp or anything else would work.

> Ordinary people in the past have done this, and ordinary people in the future will do this. And it will be the same old tech support nightmare of handling it which will lead to eventually someone implementing a "Do you really want to do that" kind of fix. Since I routinely have to help people who do this I expect that it will be enough of an issue for Red Hat eventually to put in the extra logic again as it is expensive to deal with.

Good point. Anything that becomes common and expensive needs a fix when the fix is much cheaper.


Chris Murphy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140106/19339eea/attachment.html>