From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1dd08bfb28f195e8673b3bc55198f711@ladd.quanstro.net> References: <201102181445.41877.dexen.devries@gmail.com> <1dd08bfb28f195e8673b3bc55198f711@ladd.quanstro.net> Date: Fri, 18 Feb 2011 14:49:57 -0500 Message-ID: From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b14dfc8e-ead6-11e9-9d60-3106f5b1d025 2011/2/18 erik quanstrom : >> DKIM), etc., it's just not really feasible on commodity hardware. (Of >> course, these days, operating systems and RAID controllers with >> battery-backed caches make it impossible to guarantee that your >> message ever ends up in persistent storage, but that's still a small > > bb cache is persistent storage. My bad, indeed. :-). Still, modern filesystems still raise questions as to whether the data even winds up there. Modern data stores (like Mongo) raise questions as to whether the data makes it to VFS. "We" make a lot of assumptions about quite volatile systems in the name of performance. And that's usually ok, until it isn't. It's kind of an addendum to Rob's point, actually: you can quite easily decrease the reliability / efficacy / correctness of your implementation without (or with!) the right information. And of course, there's also something to be said for eeking performance out of a system that can't perform because it's poorly designed. (I'm looking at you, Twitter.) The amount of resources they have and the amount of downtime they have are really quite extraordinary. For their popularity, you'd really expect to see an inverse correlation in one way or the other. I think I've digressed further from the original point discussed (which wasn't even the original topic) and contributed way more than I intended to, though. Food for thought. --dho > - erik > >