[belorn]

The road to compile your own kernel and build your own distribution is well documented and there is even several books on the topic. Compiling your own system from scratch without the aid of a distribution makes it easier to appreciate the automatic defaults that usually gets installed.

I personally do not want to be forced to know all the hazardously settings that exist in the kernel and base system. I want sane defaults, defaults that are set automatically when I install my Debian packages. If I disagree with an automatic default, my options are to either utilize the control (freedoms) that FOSS software provides, or issue a bug report and try get the community to agree with my views.

If "rm -rf /" is a valid use case/concern, send up a bug report. Its better than trying to remove automatic defaults from distributions.

[Lazare]

> I personally do not want to know all the hazardously settings the kernel has, where even a single mistake could spell the ruin of the whole machine.

That's kind of an ironic argument to make, given that you are using it to argue in favour of a design where a single mistake can actually brick your machine to the point that fixing it needs a soldering iron.

[detaro]

And you think in this case allowing the user to brick the system is the sane default, instead of putting it hinter an (easy to flick) switch?

[jerven]

It is behind and easy to flick switch called: su or sudo. The claim is that systemd should add a second switch because the first one is "not enough" that the systemd devs disagree with.

There are more operations that root can do that can brick a system or destroy hardware. Why should systemd try even harder to make root not do that?

[detaro]

Because working with su/sudo is still something that's often enough required for normal operations, that IMHO shouldn't have side-effects of that level. The "with great power..." spiel sudo displays is nice, but it isn't just experienced sysadmins running sudo anymore.

Since the OS doesn't provide permission levels to express this difference, it makes sense to create that isolation otherwise.

I've run rm -rf as root in the wrong directory before, and nuked stuff that required a backup to fix. I'd prefer if everything worse than that required some extra mental confirmation that, yes, I'm sure I want to do that.

[belorn]

There is always SELinux which can limit root. It was fairly easy to setup last time I tested it, and there has been attempts in the past to put it in as default.

A lot of distros also alias "rm" to "rm -i", something that many users explicitly disable. Its a complex problem of security vs usability where most discussions has been rehashed several times.

[digi_owl]

Personally i find rm too accepting, and rm -i too restrictive.

Using rm on its own will happily perform the command without further verification.

On the other hand, rm -i will request a yes/no on every last file involved.

Personally i have taken to using mc for any "complex" file system manipulations.