From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6AECA138E66 for ; Mon, 24 Feb 2014 02:50:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0659DE0B97; Mon, 24 Feb 2014 02:49:47 +0000 (UTC) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AE352E0B7C for ; Mon, 24 Feb 2014 02:49:45 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id w8so5765573qac.28 for ; Sun, 23 Feb 2014 18:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=SYrNi6/ye/+YRshOuE4ZKh7HjxHORv1XJHZMnhirNgw=; b=yY+hAI+biLHvxzYv1qEp3Z+EvCYG0Sj5E7uD0FWaz6cQl7iMvo9OQNKsMibO0RCJY/ t1Un8di20vF+6FaDxRcFSCqggjtLyNk1A2Ks64VgDEYWiXAv2A2Rg8U5SCNqupLiWB9M S144bL45bAl6W+J6njf2DThk8XYy1OQWuxDGeZ6D8jAd/MJppwpAsXeTQM172nRox208 sbVG79zQ828vnrKpbvnKGttGFEb31rJWiKtv9hJFy8btau56xzTpFXGFHU2XYWNFxtyB 2pD8rgdtdCdKLxC3DEkdGH1EPRLeE20zl1n+4KZa1GIvddkdh3/k5WOAzMA9d4XyRLnJ vM7Q== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.140.41.134 with SMTP id z6mr25782001qgz.112.1393210184973; Sun, 23 Feb 2014 18:49:44 -0800 (PST) Received: by 10.224.223.195 with HTTP; Sun, 23 Feb 2014 18:49:44 -0800 (PST) In-Reply-To: References: <52FF84CE.2050301@libertytrek.org> <530A7700.4030809@gmail.com> <201402232312.18683.michaelkintzios@gmail.com> <530A9B3D.80002@gmail.com> <20140224021041.GA17612@waltdnes.org> Date: Sun, 23 Feb 2014 21:49:44 -0500 Message-ID: Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie From: "Poison BL." To: gentoo-user Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f62935fe-4f85-47a5-8633-50a452a6b17c X-Archives-Hash: 8c46285aae52699fc2d22e210ba51072 On Sun, Feb 23, 2014 at 9:20 PM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > > On Sun, Feb 23, 2014 at 8:10 PM, Walter Dnes wrot= e: > > 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 m= e, > >> 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 wa= y. > 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=C3=A1ez Vald=C3=A9s > Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n > Universidad Nacional Aut=C3=B3noma de M=C3=A9xico > 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. --=20 Poison [BLX] Joshua M. Murphy