From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <86ipx4s36p.fsf@cmarib.ramside> References: <86ipx4s36p.fsf@cmarib.ramside> Date: Mon, 31 Jan 2011 22:45:49 -0800 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a5d060cc-ead6-11e9-9d60-3106f5b1d025 On Mon, Jan 31, 2011 at 10:02 PM, wrote: > term% mkdir trashdir && cd trashdir && mkdir x > term% touch `{i=3D0; while (test $i -lt 128) { echo -n abcdefghijklmnop; = i=3D`{echo $i+1|hoc} } } > term% cp abc* abc* x > # watch the cp executable suicide > # now, make SURE there's nothing in this rio window that you want to keep= ... > term% rm abc* > # watch the rio window go bye bye! > it's not cp and it's not rio. I think you need to diagnose this a bit better. If you look a bit more at it I think you'll see what's going on. I'm not totally in agreement with your other comments but to each his own. Yes, there are some good things that have come along in 30 years, but I have to wonder if you've been inside glibc lately. I don't think that the span of time has much if anything to do with code quality. And many of the "great ideas" of the last 30 years are not, in the end, so terribly great. There are other, very good paradigms that the code does use, such as lock-free threads. The common problem is that people come to Plan 9 and view it through the prism of their experiences with other systems such as Linux. To paraphrase the old Macintosh programming guides, "everything you know is wrong". It's really worth taking the time seeing how these ideas work before wading in with a machete and changing it all. There's a reason that things are the way they are. That doesn't mean, btw, always better; but it pays to figure out what's what first. > I'm not someone to complain without also offering solutions, though. > I'm in the process of writing some C macros that might help clean up the > source code, ensure intended bounary conditions, improve some > interfaces, etc. =A0I already have some working code, but it's still very > experimental. would be interesting to see it. I propose that you offer up your ideas of C macros etc. before too much longer. ron