From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 9 Jun 2006 17:45:29 -0700 From: Roman Shaposhnick To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] quantity vs. quality Message-ID: <20060610004529.GD2291@submarine> References: <20060610015739.GA21966@ionkov.net> <59f06232334eddd74b8f1c78efe5621b@quanstro.net> <20060610001024.GB2291@submarine> <20060610023116.GB22180@ionkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060610023116.GB22180@ionkov.net> User-Agent: Mutt/1.4.2.1i Topicbox-Message-UUID: 66dd422c-ead1-11e9-9d60-3106f5b1d025 On Fri, Jun 09, 2006 at 08:31:16PM -0600, Latchesar Ionkov wrote: > You are concentrating too much on the particular example I gave (emalloc) > and not on the issue of exiting from a library. I don't think it is a > library job to decide whether the application should die or not. You're right. But this particular example illustrates an important point which, I believe, is crucial to the spirit of Plan9. I clumsily formulate it as: its important to know when to stop solving the general problem. I believe that's the principle that helps Plan9 kernel stay away from becoming a true micro-kernel (Mach OS) or drive the abstraction ad absurdum (Spring OS) etc. It is my true belief that sometimes its better to admit that we don't know how to solve the general problem yet, than to pretend that we do. C++ and Java were supposed to relieve me from ever worrying about error handling. But did they really ? Somehow I don't see a huge stream of exceptions I get from my JVM quite regularly as a superior strategy. We don't know how to solve the general problem. Now, don't get me wrong -- sometimes you have to make an extra effort to at least pretend that it is solvable. Especially when you are in a business of building commercial software. I can appreciate it. But lets move our discussion to a practical level -- could you explain what sort of "alternative" control flow you're after when something bad happens inside the library. What kind of an ideal world solution would you like to see as an application developer ? > > Consider this -- what's worse: a fossil server that died and lost some > > of the requests or a server that tried to recover and committed random > > junk ? > > How is definitely losing data better than the possibility of writing random > junk? Because it is very easy to tell when you lost something on which you can build a comprehensive recovery strategy. Case in point: I remember a couple (5-10, actually) years ago there was an MS DOS virus detected at Stanford which, to my recollection, was the one and only one they truly feared. What the virus did was it scanned your HDD for TeX documents and carefully permuted certain characters as to keep the document a valid TeX document but alter its meaning slightly. The vote on this one was unanimous: "we'd be all better off if it just deleted them". Thanks, Roman.