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 60917138E66 for ; Mon, 24 Feb 2014 06:37:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DFE60E0B98; Mon, 24 Feb 2014 06:37:25 +0000 (UTC) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [84.201.143.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 71376E0B90 for ; Mon, 24 Feb 2014 06:37:24 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward2l.mail.yandex.net (Yandex) with ESMTP id B3D931AC0C9F for ; Mon, 24 Feb 2014 10:37:19 +0400 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 739647E006D for ; Mon, 24 Feb 2014 10:37:19 +0400 (MSK) Received: from unknown (unknown [91.233.55.8]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id jMwlZ5BciI-bJtmG2NB; Mon, 24 Feb 2014 10:37:19 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: a5cbbaee-4053-430e-ae86-e754c3c6617e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1393223839; bh=y35v6hf9oZiWBhdASrjCFZUMmXS7YDn6HV55/FRlX4A=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EWD91NUKhER9T4GZlXPFqHaPTG0ZNN/8DPBOY6m32tHYiY+31wr7gzFVjywF7YGXf IMsx81x4ZjM9PdWw9pzCiArjH58du4HOlHS4vgbCmLuR3VljIQh4f/FvGnSyc/j1tW SodAKOYVJFFsshHzU5TL89jNkJYL6Zm+YgvYpUbU= Authentication-Results: smtp11.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <530AE89B.7090203@yandex.ru> Date: Mon, 24 Feb 2014 10:37:15 +0400 From: "Yuri K. Shatroff" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie References: <52FF84CE.2050301@libertytrek.org> <530A7700.4030809@gmail.com> <201402232312.18683.michaelkintzios@gmail.com> <530A9B3D.80002@gmail.com> In-Reply-To: <530A9B3D.80002@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 98f56a6b-1f80-4da3-9da8-13db3cbb5eba X-Archives-Hash: 8b15f097567e72e88012d69c145c87a0 24.02.2014 05:07, 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." > > Doesn't sound like good design does it? Sounds more like do whatever you > think you can get away with. Good design in this area gives you > something conceptually along the lines of try...catch...finally (with > possibly some work done to avoid throwing another exception in the > finally). try...catch...finally *does* leave error handling to *the caller*. It only provides a more object-oriented way to error handling. It *does not* *handle* errors. > Unix error "design" does this: > > exit > and an error message is in $@ if you feel like looking for it Please, propose a more sound design? Take e.g. jQuery where all errors are handled by the library, it sometimes takes ages to debug why it doesn't work as expected, after a while you eagerly figure why error handling *should* be done by the caller, and the only thing the callee can do reliably is pass an error message upstream. Good error messages (and error codes, or error class hierarchy) are a different problem, but I haven't seen a more proof solution yet. > Strangely, this approach is exactly why Unix took off and got such > widespread adoption throughout the 70s. An engineer will understand that > a well-thought out design that is theoretically correct requires an > underlying design that is consistent. In the 70s, hardware consistency > was a joke - every installation was different. Consistent error handling > would severely limit the arches this new OS could run on. By taking a > "Stuff it, you deal with it coz I'm not!" approach, the handling was > fobbed off to a higher layer that was a) not really able to deal with it > and b) at least in a position to try *something*. > > By ripping out the theoretical correctness aspects, devs were left with > something that actually could compile and run. You had to bolt on your > own fancy bits to make it reliable but eventually over time these things > too stabilized into a consistent pattern (mostly by hardware vendors > going bankrupt and their stuff leaving the playing field) > > And so we come to what "Unix design" probably really is: > > "You do what you have to to get the job done, the simpler the better, > but I'm not *really* gonna hold you to that." A good design is based on: - consistency - isolation and substitution of components - component reuse - thorough documentation (a free interpretation of [1]) This almost always leads to many simple components, and that is what's called Unix design principles AFAIU. The problem of Unix is that it doesn't follow "Unix design principles" any more. But it doesn't invalidate *the principles*. > I still don't like what Lennart has done with this project, but I also > fail to see what design principle he has violated. As per [1], I fail to see what design principle he has followed. [1] http://en.wikipedia.org/wiki/Software_design#Design_concepts -- Regards, Yuri K. Shatroff