Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Poison BL.]

On Sun, Feb 23, 2014 at 9:20 PM, Canek Peláez Valdés <caneko@×××××.com> wrote:
>
> On Sun, Feb 23, 2014 at 8:10 PM, Walter Dnes <waltdnes@××××××××.org> wrote:
> > On Mon, Feb 24, 2014 at 03:07:09AM +0200, Alan McKinnon wrote
> >
> >> We don't do error handling. We don't even try and deal with it at the
> >> point it occurred, we just chuck it back up the stack, essentially
> >> giving them message "stuff it, I'm not dealing with this. You called me,
> >> you fix it."
> >
> >   The developer is not going to be psychic to the point of knowing what
> > the user *WANTED* to do, years after the code was written... or which
> > different users were expecting which different outcomes.  E.g. if
> > portage encounters a problem during a build, do you *REALLY* want it to
> > jump in and randomly patch source code and/or makefiles to get it
> > working?  NO!!! You want it to halt, with an informative error message,
> > possibly including suggestions for corrective action.
>
> But in Unix you usually don't halt, you set errno and go on your merry way.
>

Actually, from everything I've seen (and it's at least true throughout
what I've worked with in glibc) you *do* stop dead in your tracks, set
errno, and return some (hopefully indicative of a possible error)
value. In the case of standalone executables rather than library
calls, you stop where you are, if you're feeling generous you output
something to stderr on the way out the door, then exit(errno). The
process that called *you* then goes on its merry way, handling your
response of "Hey, something went wrong. Good luck." however it
chooses, if it chooses to.

> >  If I mistakenly
> > tell a system to do B, really meaning do A, that's my fault.  If I tell
> > it to do A, and it decides to do B, I will be extremely p'd off.
>
> I don't see what does that have to do with any of Alan's points.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

It ties a bit into the above, really. Concise, job specific tools that
do one thing and do them well, and don't try to magic up a guess of
what they think the user *wants* when it can't give what the user
*specifically* asked for are going to be a lot less destructive than
tools that *do* try to guess and go on their merry way (when they're
wrong) than simply handing the situation back to the user (not
necessarily the end user, just the user that asked for that tool, and
asked it to do that one job), who knows their particular
circumstances, as well as what they want in that instance.

I'll add in a very specific note that I'm not chiming in on the topic
of systemd itself, as I've yet to play with it anywhere. I'm just
chiming in on the "go on your merry way" part. The caller goes on
their merry way, not the called.

All that aside, your side of the discussions on systemd have, at
least, made me curious enough to throw together a vm to play with
sometime this week when I get time.

-- 
Poison [BLX]
Joshua M. Murphy