On Tue, 28 May 2013 09:56:49 +0000 (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> In part my post was to make it obvious that's really what we'll end
> up doing if we want any sort of robustness at all.

How much robustness do we really want?

http://engineerblogs.org/2011/04/can-a-design-be-too-robust/

> Otherwise there's simply too much that can go wrong.

You can't have too much go right, that's an unrealistic goal.

> But assuming people DO insist on traveling that road, there's only
> one way to do it robustly; thru some sort of single-user-mode by that
> name or something else.

Why reimplement something that exists? Can we reuse single user mode?
Why do we need single user mode at all?

If you're changing something as important as the init system, one should
be prepared to have an system rescue medium available to correct the
system if needed; although that is not necessarily needed if you use a
wrapper with init=/sbin/einit as you can then just drop that kernel
parameter and use the default again.

> And if it's going to be done, let's quit wasting time on all the too
> horribly brittle to think about if not simply broken methods that
> I've seen discussed,

A comparison between methods goes further than just calling the other
methods broken; this doesn't make me see your method as better, but
rather as just another method, perhaps even a broken method.

> and get to it with something that really is proven to work, a
> single-user-mode of some sort, with scripts to simplify the already
> simple and potentially break those doing something complex, sure, but
> if anything's going to work, that'd be it.  And if even that can't be
> made to work or is found not to be worth the hassle, well...

You're making a lot of statements like this but don't back them up.

Why would this work best for this situation? What's wrong with the rest?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Attachment: signature.asc
Description: PGP signature

Reply via email to