From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 24 Oct 2006 10:32:40 -0400 From: "AtomicKobold Design" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Include guards and multiple includes In-Reply-To: <52af7b0e92c11760a5b9d627fd71aa09@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7729_12454571.1161700360458" References: <219D85AA-959D-464C-90C2-0F132809F0B9@telus.net> <52af7b0e92c11760a5b9d627fd71aa09@plan9.bell-labs.com> Topicbox-Message-UUID: d40e8996-ead1-11e9-9d60-3106f5b1d025 ------=_Part_7729_12454571.1161700360458 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/20/06, geoff@plan9.bell-labs.com wrote: > > I think that one of the best arguments for organising header files as > Plan 9 does is the mess that /usr/include has become on (l)unix. It's > almost 20MB on Suse 9.1. > > Here's an interesting exercise for people who don't see a problem with > how (l)unix organises /usr/include: > > Ask someone (ideally a manager, the higher the rank, the better) to > find out where under /usr/include on Linux the type time_t is defined > and the signal SIGINT is declared without using grep or any > equivalent; they should trace through the include files visually. If > they return with the correct answers and aren't disgusted with the > mess under /usr/include, slap some pointy hair on them. > > Yes I agree, they are even larger under S.L.E.D. 10, I believe like 35 MB, or some such. IMHO organizing header files. As far as the above "exercise" no way w/o grep would I in a million years wanna go through /usr/include in a *nix system. ------=_Part_7729_12454571.1161700360458 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/20/06, geoff@plan9.bell-labs.com <geoff@plan9.bell-labs.com > wrote:
I think that one of the best arguments for organising header files as
Plan 9 does is the mess that /usr/include has become on (l)unix.  It's
almost 20MB on Suse 9.1.

Here's an interesting exercise for people who don't see a problem with
how (l)unix organises /usr/include:

Ask someone (ideally a manager, the higher the rank, the better) to
find out where under /usr/include on Linux the type time_t is defined
and the signal SIGINT is declared without using grep or any
equivalent; they should trace through the include files visually.  If
they return with the correct answers and aren't disgusted with the
mess under /usr/include, slap some pointy hair on them.


Yes I agree, they are even larger under S.L.E.D. 10, I believe like 35 MB, or some such.
IMHO organizing header files.

As far as the above "exercise" no way w/o grep would I in a million years wanna go through
/usr/include in a *nix system.


------=_Part_7729_12454571.1161700360458--