1997-02-13 - Re: Recommendation: Creation of “alt.cypherpunks”

Header Data

From: ichudov@algebra.com (Igor Chudov @ home)
To: cypherpunks@algebra.com
Message Hash: a13ca8f9c7755fc3f9c33a0cd21575a81b8245f5ae9fb455fde91e543e6be876
Message ID: <199702131535.JAA20917@manifold.algebra.com>
Reply To: <o7D32D23w165w@bwalk.dm.com>
UTC Datetime: 1997-02-13 15:39:21 UTC
Raw Date: Thu, 13 Feb 1997 07:39:21 -0800 (PST)

Raw message

From: ichudov@algebra.com (Igor Chudov @ home)
Date: Thu, 13 Feb 1997 07:39:21 -0800 (PST)
To: cypherpunks@algebra.com
Subject: Re: Recommendation: Creation of "alt.cypherpunks"
In-Reply-To: <o7D32D23w165w@bwalk.dm.com>
Message-ID: <199702131535.JAA20917@manifold.algebra.com>
MIME-Version: 1.0
Content-Type: text


Dr.Dimitri Vulis KOTM wrote:
> ichudov@algebra.com writes:
> > > 1. A newsgroup like comp.privacy.cypherpunks will be carried on a lot of
> > > corprate news servers that don't carry alt.* (or even soc.*). Note that
> > > soc.org.cypherpunks is inappropriate since cp is *not* an organization. :-)
> > > Another possibility is sci.crypto.cypherpunks. (True, people whose corporat
> > > newsservers don't carry soc.* and talk.* can use dejanews - provided their
> > > firewall lets them.)
> >
> > > 2. It takes more work to create a comp.* newsgroup than an alt newsgroup.
> > > It takes a vote. I'm willing to be one of the proponents and generally help
> > > with the process. (Both I and Igor have been co-proponents of major Usenet
> > > newsgroups - don't know about other people onthis list. :-)
> >
> > Not only it takes a vote. What is more important is what a vote gives:
> > a good discussion of the newsgroup and the formal RFD/RFD/CFV process
> > ensures that, on average, a good balance is found between various groups
> > of readers.
> >
> > I am not concerned as to what the name of the group will be, it is
> > not important. What is important is that it should be in a more or
> > less flame-free zone.
> 
> I'm concerned about smart people stuck behind corporate firewalls
> and able to see comp.* and sci.*. Nearly every big Wall St firm
> is that way. Did I ever relate to you the story how I had to
> break through the firwall at GS to accomplish mywork?

Would be interesting.

> > It is too late to stop alt.cypherpunks, but if I had to make a
> > prediction again, I would predict that soon posters will BEG to help
> > them create comp.*.cypherpunks, because of spam and alt.flamage.
> 
> Timmy has a valid point: the reason why a comp.* newsgroup might have less
> cross-posted and "off-topic" crap is because net.cops would be more
> likely to complain to posters' sysadmins. Having a charter state that
> cypherpunks have technical means to ignore traffic they don't like,
> and don't need anyone forging cancels or complaining to sysadmins
> or otherwise getting silenced, is a good idea.

It is not only because of that. There are two categories of people
who simply do not visit com.* groups: sex spammers and trollers
(who post articles like I RAPED A NIGGER CHILD to tens of newsgroups).

If the group is created in a space that is isolated from them, that is
already good.

As for net.cops, check out what Scott Nudds does in comp.lang.c++

> What's going to happen when (not if) someone posts something in
> alt.cypherpunks that Chris Lewis (spit) judges to be "spam"
> and forges a cancel? Or someone posts a binary and Richard
> "little dick" Depew forges a cancel?

Chris Lewis can exclude newsgroups from his spam watch. I think that
if cypherpunks put something forbidding third party cancels into the
charter, he will not cancel stuff posted there.

> > > 3. An unmoderated Usenet newsgroup would have even ore crap than this maili
> > > list. I've been thinking of how to deal with crap, and with the obvious des
> > > by some people to delegate their decision what to read and what not to read
> > > to other people.
> >
> > It is alt.* and soc.* that has most crap, sci and comp are way better.
> 
> There's a bunch of net.cops in e.g. comp.lang.eiffel that complain to
> sysadmins of anyone posting to that newsgroup who's in a member of the
> "in" crowd". It may or may not cut down on the crap, but is it worth it?

Yes, there is a notorious net.cop The Right Reverend Colin James III (spit).

A sample of his stukachestvo is attached at the bottom of this letter.


>From ares.csd.net!cjames  Fri Dec  8 00:00:29 1995
Return-Path: <cjames@ares.csd.net>
Received: from ares.csd.net by espcbw.stat.ncsu.edu.stat.ncsu.edu with smtp
        (Smail3.1.29.1 #5) id m0tNxjG-000EDPC; Fri, 8 Dec 95 00:00 PST
Received: by ares.csd.net (5.65/DEC-Ultrix/4.3)
        id AA08055; Thu, 7 Dec 1995 22:02:44 -0700
Message-Id: <9512080502.AA08055@ares.csd.net>
From: cjames@ares.csd.net (Colin James III (The Rt Rev'd))
To: ichudov@espcbw.stat.ncsu.edu (Igor Chudov),
        postmaster@espcbw.stat.ncsu.edu, postmaster@stat.ncsu.edu,
        postmaster@ncsu.edu
Subject: Re: Nauseating typedefs -- pros and cons
Date: Fri, 08 Dec 1995 03:13:53 GMT
Organization: CEC Services
Reply-To: cjames@ares.csd.net
References: <461dph$ske@saba.info.ucla.edu> <48np3j$1b4@solutions.solon.com> <4a
7rpv$fj@taco.cc.ncsu.edu>
X-Mailer: Forte Agent .99b.112
Status: RO

On 7 Dec 1995 23:02:23 GMT, ichudov@espcbw.stat.ncsu.edu (Igor Chudov)
wrote with possible deletions:

| Douglas Evan Cook (cookd@bert.cs.byu.edu) wrote:
| *                     The real question comes down to: when do you need to 
| * use INT32 or INT16?  Usually, you only need it when you are saving info 
| * to a disk or when you need to make sure that your numbers won't 
| * overflow.  A little bit of hardware control is also given.  But when you 
| * don't get those advantages, a plain int is just great.
| 
| It is NOT great at all. Each variable is associated with a range of
| values. This range of values comes from the requirements of external world. 
| Say, some program _must_ be required by business rules to store
| $$ amount as an integer value, and it may be specified in the
| requirements that $$amount cannot be more than $1,000,000. If I,
| as a careless programmer, program variable dollar_amount as int
| just because my RS6000 has 32-bit ints, this program will NOT be
| portable to 16-bit computers.
| 
| You can invent an untold amount of such situations. If I defined
| DollarAmount_t as UINT32, I would effectively avoid this trouble.
| 
| * So for your scanf 
| * vars, just use ints.  Then do range checking and then assign them into 
| * the UINT16 type or whatever only if you need to.
| 
| The solution is very simple and cool (IMHO). 
| 
| In the same file where you define INT16, UINT32, etc, add the following: 
| 
| #ifdef AIX
|   typedef long INT32;
|   #define F_INT32 "ld"
| 
|   typedef unsigned short UINT16;
|   #define F_UINT16 "u"
| #endif
| 
| #ifdef YOUR_FAVORITE_MACHINE
|   typedef short INT32; // Maybe for 64-bit machines, never worked with them
|   #define F_INT32 "d"
| ... etc etc ...
| 
| Then you define your user types: 
| 
|   typedef INT32 DollarAmount_t;
|   #define DollarAmount_f INT32_F // You make it a rule to define
|                                  // formats right along with types
| 
| Usually, in scanf (and printf) people write things like this: 
| 
|       printf( "%ld is the dollar amount for customer %4.4d\n", 
|               amount, cust );
| 
| Instead, you write
| 
|       printf( "%" DollarAmount_f " is the dollar amount for customer "
|               "%4.4" Cust_f,
|               amount, cust );
| 
| It is a totally portable code. All you need to port primitive types 
| is to recompile it.
| 
| -- 
|    - Igor. (My opinions only) http://www.algebra.com/~ichudov/index.html
|    For public PGP key, finger me or send email with Subject "send pgp key"
| 
| You know you have achieved perfection in design, not when you have nothing 
| more to add, but when you have nothing more to take away.
|                           - Antoine de Saint Exupery.

Kindly remove comp.lang.eiffel from distribution of this thread.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Colin James III, Principal Scientist           cjames@csd.net
CEC Services, 2080 Kipling St, Lakewood, CO  80215-1502   USA
Voice: 303.231.9437;  Facsimile: .231.9438;  Data:  .231.9434  
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~


	- Igor.





Thread