From Administration at computeradmin.org  Mon Apr  5 17:31:46 2004
From: Administration at computeradmin.org (Admin)
Date: Tue, 06 Apr 04 00:31:46 GMT
Subject: [CPLUG Chatter] ADV:        Attention All  Nonprofit Orgs: (Members, Staff and  Associates):
Message-ID: <sunjw96b-hyx301v4e-q379@0loj.0g.mp>

Attention All Nonprofit Organizations, Members, Staff and Associates:

You Must Respond By 5 P.M. Wednesday, April 7, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Members, Staff and Associates
who respond to this message before 5 P.M., Wednesday, April 7, 2004.

All desktop computers are brand-new packed in their original boxes,
and come with a full manufacturer's warranty plus
a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

    1-800-884-9510 by 5 P.M. Wednesday, April 7, 2004

The fast and powerful AT-2400 series Desktop features: 

      * Intel 2.0Ghz Processor for amazing speed and performance
      * 128MB DDR RAM,  --- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB
      * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW 
      * 1.44 Floppy disk drive
      * Next Generation Technology
      * ATI Premium video and sound
      * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $699 ........................................ Your Cost $297

How to qualify:

  1. You must be a Member, Staff or Associate of a Nonprofit:
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-884-9510 by 5 P.M. Wednesday, April 7, 2004
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.
   
   
Call Avtech Direct
1-800-884-9510 before 5 P.M. Wednesday, April 7, 2004




If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp

From cplug at condordes.net  Wed Apr  7 15:14:42 2004
From: cplug at condordes.net (Joshua J. Berry)
Date: Wed, 7 Apr 2004 15:14:42 -0700
Subject: [CPLUG Chatter] Fwd: [IP] Interesting speculation on the tech behind gmail
Message-ID: <200404071514.43729.cplug@condordes.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thought you guys might find this interesting.

- ----------  Forwarded Message  ----------

Subject: [IP] Interesting speculation on the tech behind gmail
Date: Tuesday 06 April 2004 01:31
From: Dave Farber <dave at farber.net>
To: ip at v2.listbox.com

Delivered-To: dfarber+ at ux13.sp.cs.cmu.edu
Date: Tue, 06 Apr 2004 13:56:09 +0530
From: Suresh Ramasubramanian <suresh at hserus.net>
Subject: Interesting speculation on the tech behind gmail
To: Dave Farber <dave at farber.net>

http://blog.topix.net/archives/000016.html

April 04, 2004
The Secret Source of Google's Power
Much is being written about Gmail, Google's new free webmail system.
There's something deeper to learn about Google from this product than the
initial reaction to the product features, however. Ignore for a moment the
observations about Google leapfrogging their competitors with more user
value and a new feature or two. Or Google diversifying away from search
into other applications; they've been doing that for a while. Or the
privacy red herring.

No, the story is about seemingly incremental features that are actually
massively expensive for others to match, and the platform that Google is
building which makes it cheaper and easier for them to develop and run
web-scale applications than anyone else.

I've written before about Google's snippet service, which required that
they store the entire web in RAM. All so they could generate a slightly
better page excerpt than other search engines.

Google has taken the last 10 years of systems software research out of
university labs, and built their own proprietary, production quality
system. What is this platform that Google is building? It's a distributed
computing platform that can manage web-scale datasets on 100,000 node
server clusters. It includes a petabyte, distributed, fault tolerant
filesystem, distributed RPC code, probably network shared memory and
process migration. And a datacenter management system which lets a handful
of ops engineers effectively run 100,000 servers. Any of these projects
could be the sole focus of a startup.

Speculation: Gmail's Architecture and Economics

Let's make some guesses about how one might build a Gmail.

Hotmail has 60 million users. Gmail's design should be comparable, and
should scale to 100 million users. It will only have to support a couple of
million in the first year though.

The most obvious challenge is the storage. You can't lose people's email,
and you don't want to ever be down, so data has to be replicated. RAID is
no good; when a disk fails, a human needs to replace the bad disk, or there
is risk of data loss if more disks fail. One imagines the old ENIAC
technician running up and down the isles of Google's data center with a
shopping cart full of spare disk drives instead of vacuum tubes. RAID also
requires more expensive hardware -- at least the hot swap drive trays. And
RAID doesn't handle high availability at the server level anyway.

No. Google has 100,000 servers. [nytimes] If a server/disk dies, they leave
it dead in the rack, to be reclaimed/replaced later. Hardware failures need
to be instantly routed around by software.

Google has built their own distributed, fault-tolerant, petabyte
filesystem, the Google Filesystem. This is ideal for the job. Say GFS
replicates user email in three places; if a disk or a server dies, GFS can
automatically make a new copy from one of the remaining two. Compress the
email for a 3:1 storage win, then store user's email in three locations,
and their raw storage need is approximately equivalent to the user's mail
 size.

The Gmail servers wouldn't be top-heavy with lots of disk. They need the
CPU for indexing and page view serving anyway. No fancy RAID card or
hot-swap trays, just 1-2 disks per 1U server.

It's straightforward to spreadsheet out the economics of the service,
taking into account average storage per user, cost of the servers, and
monetization per user per year. Google apparently puts the operational cost
of storage at $2 per gigabyte. My napkin math comes up with numbers in the
same ballpark. I would assume the yearly monetized value of a webmail user
to be in the $1-10 range.

Cheap Hardware

Here's an anecdote to illustrate how far Google's cultural approach to
hardware cost is different from the norm, and what it means as a component
of their competitive advantage.

In a previous job I specified 40 moderately-priced servers to run a new
internet search site we were developing. The ops team overrode me; they
wanted 6 more expensive servers, since they said it would be easier to
manage 6 machines than 40.

What this does is raise the cost of a CPU second. We had engineers that
could imagine algorithms that would give marginally better search results,
but if the algorithm was 10 times slower than the current code, ops would
have to add 10X the number of machines to the datacenter. If you've already
got $20 million invested in a modest collection of Suns, going 10X to run
some fancier code is not an option.

Google has 100,000 servers.

Any sane ops person would rather go with a fancy $5000 server than a bare
$500 motherboard plus disks sitting exposed on a tray. But that's a 10X
difference to the cost of a CPU cycle. And this frees up the algorithm
designers to invent better stuff.

Without cheap CPU cycles, the coders won't even consider algorithms that
the Google guys are deploying. They're just too expensive to run.

Google doesn't deploy bare motherboards on exposed trays anymore; they're
on at least the fourth iteration of their cheap hardware platform. Google
now has an institutional competence building and maintaining servers that
cost a lot less than the servers everyone else is using. And they do it
with fewer people.

Think of the little internal factory they must have to deploy servers, and
the level of automation needed to run that many boxes. Either network boot
or a production line to pre-install disk images. Servers that
self-configure on boot to determine their network config and load the
latest rev of the software they'll be running. Normal datacenter ops
practices don't scale to what Google has.
What are all those OS Researchers doing at Google?

Rob Pike has gone to Google. Yes, that Rob Pike -- the OS researcher, the
member of the original Unix team from Bell Labs. This guy isn't just some
labs hood ornament; he writes code, lots of it. Big chunks of whole new
operating systems like Plan 9.

Look at the depth of the research background of the Google employees in OS,
networking, and distributed systems. Compiler Optimization. Thread
migration. Distributed shared memory.

I'm a sucker for cool OS research. Browsing papers from Google employees
about distributed systems, thread migration, network shared memory, GFS,
makes me feel like a kid in Tomorrowland wondering when we're going to
Mars. Wouldn't it be great, as an engineer, to have production versions of
all this great research.

Google engineers do!

Competitive Advantage

Google is a company that has built a single very large, custom computer.
It's running their own cluster operating system. They make their big
computer even bigger and faster each month, while lowering the cost of CPU
cycles. It's looking more like a general purpose platform than a cluster
optimized for a single application.

While competitors are targeting the individual applications Google has
deployed, Google is building a massive, general purpose computing platform
for web-scale programming.

This computer is running the world's top search engine, a social networking
service, a shopping price comparison engine, a new email service, and a
local search/yellow pages engine. What will they do next with the world's
biggest computer and most advanced operating system?

Posted by skrenta at April 4, 2004 02:11 PM | TrackBack

- -------------------------------------
You are subscribed as condor-ip at condordes.net
To manage your subscription, go to
  http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/

- -------------------------------------------------------

- -- 

- -----------------------------------------
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

NOTE: Please do not submit this email address to any mailing
lists or websites without prior permission.  Thank you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAdH1SaIxeYlQMsxsRAqLzAJ9EqK+KjZV9kDY7JFcXBtHDl+n/VACgm/DY
RIri4vAueuSug+sabQF/mbM=
=DZ2c
-----END PGP SIGNATURE-----



From matt68000 at mac.com  Wed Apr  7 18:01:46 2004
From: matt68000 at mac.com (matthew du puy)
Date: Wed, 07 Apr 2004 17:01:46 -0800
Subject: [CPLUG Chatter] Off topic google bash
In-Reply-To: <200404071514.43729.cplug@condordes.net>
Message-ID: <BC99E47A.494B%matt68000@mac.com>

Off topic google bash (don't get me wrong, I like google a lot)

> they store the entire web in RAM.

It frightens me that people think this. I've had to do searches on subjects
that are very specific but by no means obscure and google has failed to
index relevant information.

teoma.com has been very helpful in unearthing things that google doesn't
have indexed and vivisimo.com (using lycos) turns up all sorts of garbage
that google doesn't and categorizes it automatically (like entire cplug
discussion threads).

For everyday, simple info google is by far the best engine today but
assuming that they index the entire web is just silly. To do a thorough
search on specific topics, it usually pays off to use google plus the other
two engines I mentioned above.


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thought you guys might find this interesting.
> 
> - ----------  Forwarded Message  ----------
> 
> Subject: [IP] Interesting speculation on the tech behind gmail
> Date: Tuesday 06 April 2004 01:31
> From: Dave Farber <dave at farber.net>
> To: ip at v2.listbox.com
> 
> Delivered-To: dfarber+ at ux13.sp.cs.cmu.edu
> Date: Tue, 06 Apr 2004 13:56:09 +0530
> From: Suresh Ramasubramanian <suresh at hserus.net>
> Subject: Interesting speculation on the tech behind gmail
> To: Dave Farber <dave at farber.net>
> 
> http://blog.topix.net/archives/000016.html
> 
> April 04, 2004
> The Secret Source of Google's Power
> Much is being written about Gmail, Google's new free webmail system.
> There's something deeper to learn about Google from this product than the
> initial reaction to the product features, however. Ignore for a moment the
> observations about Google leapfrogging their competitors with more user
> value and a new feature or two. Or Google diversifying away from search
> into other applications; they've been doing that for a while. Or the
> privacy red herring.
> 
> No, the story is about seemingly incremental features that are actually
> massively expensive for others to match, and the platform that Google is
> building which makes it cheaper and easier for them to develop and run
> web-scale applications than anyone else.
> 
> I've written before about Google's snippet service, which required that
> they store the entire web in RAM. All so they could generate a slightly
> better page excerpt than other search engines.
> 
> Google has taken the last 10 years of systems software research out of
> university labs, and built their own proprietary, production quality
> system. What is this platform that Google is building? It's a distributed
> computing platform that can manage web-scale datasets on 100,000 node
> server clusters. It includes a petabyte, distributed, fault tolerant
> filesystem, distributed RPC code, probably network shared memory and
> process migration. And a datacenter management system which lets a handful
> of ops engineers effectively run 100,000 servers. Any of these projects
> could be the sole focus of a startup.
> 
> Speculation: Gmail's Architecture and Economics
> 
> Let's make some guesses about how one might build a Gmail.
> 
> Hotmail has 60 million users. Gmail's design should be comparable, and
> should scale to 100 million users. It will only have to support a couple of
> million in the first year though.
> 
> The most obvious challenge is the storage. You can't lose people's email,
> and you don't want to ever be down, so data has to be replicated. RAID is
> no good; when a disk fails, a human needs to replace the bad disk, or there
> is risk of data loss if more disks fail. One imagines the old ENIAC
> technician running up and down the isles of Google's data center with a
> shopping cart full of spare disk drives instead of vacuum tubes. RAID also
> requires more expensive hardware -- at least the hot swap drive trays. And
> RAID doesn't handle high availability at the server level anyway.
> 
> No. Google has 100,000 servers. [nytimes] If a server/disk dies, they leave
> it dead in the rack, to be reclaimed/replaced later. Hardware failures need
> to be instantly routed around by software.
> 
> Google has built their own distributed, fault-tolerant, petabyte
> filesystem, the Google Filesystem. This is ideal for the job. Say GFS
> replicates user email in three places; if a disk or a server dies, GFS can
> automatically make a new copy from one of the remaining two. Compress the
> email for a 3:1 storage win, then store user's email in three locations,
> and their raw storage need is approximately equivalent to the user's mail
> size.
> 
> The Gmail servers wouldn't be top-heavy with lots of disk. They need the
> CPU for indexing and page view serving anyway. No fancy RAID card or
> hot-swap trays, just 1-2 disks per 1U server.
> 
> It's straightforward to spreadsheet out the economics of the service,
> taking into account average storage per user, cost of the servers, and
> monetization per user per year. Google apparently puts the operational cost
> of storage at $2 per gigabyte. My napkin math comes up with numbers in the
> same ballpark. I would assume the yearly monetized value of a webmail user
> to be in the $1-10 range.
> 
> Cheap Hardware
> 
> Here's an anecdote to illustrate how far Google's cultural approach to
> hardware cost is different from the norm, and what it means as a component
> of their competitive advantage.
> 
> In a previous job I specified 40 moderately-priced servers to run a new
> internet search site we were developing. The ops team overrode me; they
> wanted 6 more expensive servers, since they said it would be easier to
> manage 6 machines than 40.
> 
> What this does is raise the cost of a CPU second. We had engineers that
> could imagine algorithms that would give marginally better search results,
> but if the algorithm was 10 times slower than the current code, ops would
> have to add 10X the number of machines to the datacenter. If you've already
> got $20 million invested in a modest collection of Suns, going 10X to run
> some fancier code is not an option.
> 
> Google has 100,000 servers.
> 
> Any sane ops person would rather go with a fancy $5000 server than a bare
> $500 motherboard plus disks sitting exposed on a tray. But that's a 10X
> difference to the cost of a CPU cycle. And this frees up the algorithm
> designers to invent better stuff.
> 
> Without cheap CPU cycles, the coders won't even consider algorithms that
> the Google guys are deploying. They're just too expensive to run.
> 
> Google doesn't deploy bare motherboards on exposed trays anymore; they're
> on at least the fourth iteration of their cheap hardware platform. Google
> now has an institutional competence building and maintaining servers that
> cost a lot less than the servers everyone else is using. And they do it
> with fewer people.
> 
> Think of the little internal factory they must have to deploy servers, and
> the level of automation needed to run that many boxes. Either network boot
> or a production line to pre-install disk images. Servers that
> self-configure on boot to determine their network config and load the
> latest rev of the software they'll be running. Normal datacenter ops
> practices don't scale to what Google has.
> What are all those OS Researchers doing at Google?
> 
> Rob Pike has gone to Google. Yes, that Rob Pike -- the OS researcher, the
> member of the original Unix team from Bell Labs. This guy isn't just some
> labs hood ornament; he writes code, lots of it. Big chunks of whole new
> operating systems like Plan 9.
> 
> Look at the depth of the research background of the Google employees in OS,
> networking, and distributed systems. Compiler Optimization. Thread
> migration. Distributed shared memory.
> 
> I'm a sucker for cool OS research. Browsing papers from Google employees
> about distributed systems, thread migration, network shared memory, GFS,
> makes me feel like a kid in Tomorrowland wondering when we're going to
> Mars. Wouldn't it be great, as an engineer, to have production versions of
> all this great research.
> 
> Google engineers do!
> 
> Competitive Advantage
> 
> Google is a company that has built a single very large, custom computer.
> It's running their own cluster operating system. They make their big
> computer even bigger and faster each month, while lowering the cost of CPU
> cycles. It's looking more like a general purpose platform than a cluster
> optimized for a single application.
> 
> While competitors are targeting the individual applications Google has
> deployed, Google is building a massive, general purpose computing platform
> for web-scale programming.
> 
> This computer is running the world's top search engine, a social networking
> service, a shopping price comparison engine, a new email service, and a
> local search/yellow pages engine. What will they do next with the world's
> biggest computer and most advanced operating system?
> 
> Posted by skrenta at April 4, 2004 02:11 PM | TrackBack
> 
> - -------------------------------------
> You are subscribed as condor-ip at condordes.net
> To manage your subscription, go to
> http://v2.listbox.com/member/?listname=ip
> 
> Archives at: http://www.interesting-people.org/archives/interesting-people/
> 
> - -------------------------------------------------------
> 
> - -- 
> 
> - -----------------------------------------
> Joshua J. Berry
> 
> "I haven't lost my mind -- it's backed up on tape somewhere."
>   -- /usr/games/fortune
> 
> NOTE: Please do not submit this email address to any mailing
> lists or websites without prior permission.  Thank you.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFAdH1SaIxeYlQMsxsRAqLzAJ9EqK+KjZV9kDY7JFcXBtHDl+n/VACgm/DY
> RIri4vAueuSug+sabQF/mbM=
> =DZ2c
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Chatter mailing list
> Chatter at lists.cplug.org
> http://lists.cplug.org/mailman/listinfo/chatter



From chad at tindel.net  Sat Apr 10 19:01:02 2004
From: chad at tindel.net (Chad N. Tindel)
Date: Sat, 10 Apr 2004 22:01:02 -0400
Subject: [CPLUG Chatter] Re: [CPLUG] excute a process in kernel
In-Reply-To: <200404110052.i3B0qkld000047@falcon.csc.calpoly.edu>
References: <200404110052.i3B0qkld000047@falcon.csc.calpoly.edu>
Message-ID: <20040411020102.GA85534@calma.pair.com>

> >What do you teach anyway?  Part of the problem is that I've never met you
> >so its hard to gauge the way you think or what you value as important.
> 
> 	Programming Languages mostly.  Though I certainly have interests
> in Operating Systems.  This probably explains my interest in this discussion.
> It certainly explains why I mentioned Erlang.

Indeed it does.  I'll have to admit, I didn't expect anybody to bring that
up!  :)

> >Whoah.  How did we get to the differences being minimal?  At the very
> >least, there will always be the issue of different behaviors from different
> >thread implementations on different operating systems, which is a HUGE
> >difference if you're porting, say, a 1 million line application.
> 
> 	I'll agree with that.  At a relatively abstract level, programming
> with multiple threads has similar concerns as programming with multiple
> processes.  If they are part of the same "program", then they must
> communicate/synchronize in some way.  At that level, I view them as very
> similar.  When you're looking at the differences in actual implementation,
> especially when porting, then they are not quite as similar.

Hmmm... maybe that is the main reason why we're debating.  
As an architect, I'm chiefly concerned with designing systems that are to
an extent easily built, but to an even greater extent, easily maintained and
extended for future requirements (since this is where most projects spend
their lifetime).  

When I was at Poly, which wasn't that long ago, I recall
professors talking about how programs spent most of their time and money
in verification and maintenance, but nobody ever offered any real world
suggestions for how to optimize that part.  "Clean design" was really the
only thing they could say, but even that was kind of nebulous.  Sort of "you'll
know it when you see it".

If there's one piece of advice I can give to students who are about to join
the ranks of industry programmers, it would be "Threads are evil.  Don't use
them unless there is absolutely no other way to meet the requirements 
imposed on you, because it cause you more pain in testing and maintenance
than you can ever imagine".  

Chad


From akeen at falcon.csc.calpoly.edu  Sat Apr 10 19:13:50 2004
From: akeen at falcon.csc.calpoly.edu (Aaron Keen)
Date: Sat, 10 Apr 2004 19:13:50 -0700 (PDT)
Subject: [CPLUG Chatter] Re: [CPLUG] Long discussion of threads
Message-ID: <200404110213.i3B2Dota002216@falcon.csc.calpoly.edu>

>Hmmm... maybe that is the main reason why we're debating.  
>As an architect, I'm chiefly concerned with designing systems that are to
>an extent easily built, but to an even greater extent, easily maintained and
>extended for future requirements (since this is where most projects spend
>their lifetime).  

	These are incredibly important concerns.  I think the reason we're
debating is simply that I don't believe that threads are useless.

>When I was at Poly, which wasn't that long ago, I recall
>professors talking about how programs spent most of their time and money
>in verification and maintenance, but nobody ever offered any real world
>suggestions for how to optimize that part.  "Clean design" was really the
>only thing they could say, but even that was kind of nebulous.  Sort of "you'll
>know it when you see it".

	Unfortunately, it is a bit nebulous.  I think it is kind of "you'll
know it when you see it," but perhaps a little more of "once you work with
a bad design, you'll better appreciate how to improve it."  To the extent
possible given our limited time during the quarter, I think it is useful to
work on larger projects wherein students can see the consequences of poor
design and, hopefully, take away experience on how to better structure the
code the next time.  Though in few classes will one gain experience in
maintaining large systems.  There is no substitute for real world experience.

>If there's one piece of advice I can give to students who are about to join
>the ranks of industry programmers, it would be "Threads are evil.  Don't use
>them unless there is absolutely no other way to meet the requirements 
>imposed on you, because it cause you more pain in testing and maintenance
>than you can ever imagine".  

	I respect the sentiment, but I imagine that if you could only give
one piece of advice to students you could come up with something else of
more importance.  Maybe something about buffer overflows, or assumptions
about user input, or tabs in source code. ;-)

-Aaron





From chad at tindel.net  Sat Apr 10 19:41:36 2004
From: chad at tindel.net (Chad N. Tindel)
Date: Sat, 10 Apr 2004 22:41:36 -0400
Subject: [CPLUG Chatter] Re: [CPLUG] Long discussion of threads
In-Reply-To: <200404110213.i3B2Dota002216@falcon.csc.calpoly.edu>
References: <200404110213.i3B2Dota002216@falcon.csc.calpoly.edu>
Message-ID: <20040411024136.GA12718@calma.pair.com>

> >When I was at Poly, which wasn't that long ago, I recall
> >professors talking about how programs spent most of their time and money
> >in verification and maintenance, but nobody ever offered any real world
> >suggestions for how to optimize that part.  "Clean design" was really the
> >only thing they could say, but even that was kind of nebulous.  Sort of "you'll
> >know it when you see it".
> 
> 	Unfortunately, it is a bit nebulous.  I think it is kind of "you'll
> know it when you see it," but perhaps a little more of "once you work with
> a bad design, you'll better appreciate how to improve it."  To the extent
> possible given our limited time during the quarter, I think it is useful to
> work on larger projects wherein students can see the consequences of poor
> design and, hopefully, take away experience on how to better structure the
> code the next time.  Though in few classes will one gain experience in
> maintaining large systems.  There is no substitute for real world experience.

Hmmm... what kind of projects do you guys assign that help students
"see the consequences of poor design"?

And I'm not disagreeing with that.  I can't think of a way to teach anyone
how to design well.  Which is yet another reason for concentrating on things
that you can teach, like formal verification and concerns when 
working/designing on large systems.

And I completely agree with your statement about real world experience.  Every
year I'm extremely shocked to find that we can't find candidates who want to do
6-9 month co-ops.  Everybody seems to want to do 3 month co-ops so they can
"graduate on time".  Maybe you can help pass the word along to your students
and fellow faculty members (so they can tell their students) that people will
have a much easier time finding a job when they graduate if they have a couple
of 6 or 9 month co-ops under their belt.  No one has ever explained to me
why students don't want to take these opportunities.  

> >If there's one piece of advice I can give to students who are about to join
> >the ranks of industry programmers, it would be "Threads are evil.  Don't use
> >them unless there is absolutely no other way to meet the requirements 
> >imposed on you, because it cause you more pain in testing and maintenance
> >than you can ever imagine".  
> 
> 	I respect the sentiment, but I imagine that if you could only give
> one piece of advice to students you could come up with something else of
> more importance.  Maybe something about buffer overflows, or assumptions
> about user input, or tabs in source code. ;-)

Not really.  All of those things are so obviously correct that a teacher
can say them, the student can think about it, and convince themselves they
are correct in about 10 seconds.  About the only other thing I can think of
that is of equal importance is to always use a text protocol for communicating
between two processes.  You inevitably have endian issues if you design
binary protocols.  Almost every real language has an XML parser available with
it though, so there are very few reasons not to use it.

Chad


From akeen at falcon.csc.calpoly.edu  Sat Apr 10 20:22:40 2004
From: akeen at falcon.csc.calpoly.edu (Aaron Keen)
Date: Sat, 10 Apr 2004 20:22:40 -0700 (PDT)
Subject: [CPLUG Chatter] Re: [CPLUG] Long discussion of threads
Message-ID: <200404110322.i3B3MeOV003737@falcon.csc.calpoly.edu>

>Hmmm... what kind of projects do you guys assign that help students
>"see the consequences of poor design"?

	Thus far, for my projects this isn't as much of an explicit
aspect of the assignment, but more of an artifact.  I've been assigning
the implementation of an interpreter for a small imperative language as
the first programming assignment in the languages course.  This is a
relatively large project that can lead to a number of different designs.
Simply by virtue of the size of the project (as compared to the assignments
done in the earlier 101-103 classes), many students start to see where
their design could be improved for "next time."  The followup assignment
requires an extension to the interpreter.  The students are allowed to
either extend their initial implementation (if functional) or a provided
solution.  In one case, the student must face any consequences of his/her
design.  In the other case, the student must extend a program with a
foreign design.  This is not, however, the primary goal of the assignments.

	There other examples that one could draw from the software engineering
courses and some technical elective courses, but I don't know the details of
such projects.

>And I'm not disagreeing with that.  I can't think of a way to teach anyone
>how to design well.  Which is yet another reason for concentrating on things
>that you can teach, like formal verification and concerns when 
>working/designing on large systems.

	It is my understanding that formal verification and working/designing
large systems is discussed in the software engineering courses.  But I have
had little exposure to those classes here, so I don't know the details.

>And I completely agree with your statement about real world experience.  Every
>year I'm extremely shocked to find that we can't find candidates who want to do
>6-9 month co-ops.  Everybody seems to want to do 3 month co-ops so they can
>"graduate on time".  Maybe you can help pass the word along to your students
>and fellow faculty members (so they can tell their students) that people will
>have a much easier time finding a job when they graduate if they have a couple
>of 6 or 9 month co-ops under their belt.  No one has ever explained to me
>why students don't want to take these opportunities.  

	That's an interesting point.  I don't know how many of our students
know about 6-9 month co-ops.  I imagine that part of the reason might have
to do with the mindset of "finishing" school and getting out into the real
world.  A perception that any time off from school will delay this venture
into the next phase of life.

>> more importance.  Maybe something about buffer overflows, or assumptions
>> about user input, or tabs in source code. ;-)
>
>Not really.  All of those things are so obviously correct that a teacher
>can say them, the student can think about it, and convince themselves they
>are correct in about 10 seconds.  About the only other thing I can think of

	Those examples were meant as jokes.  But it certainly says a lot
about the subject if you feel the statement about threads is really the
most important advice you can give.

>that is of equal importance is to always use a text protocol for communicating
>between two processes.  You inevitably have endian issues if you design
>binary protocols.  Almost every real language has an XML parser available with
>it though, so there are very few reasons not to use it.

	This is where you might also run into a debate about performance
vs. maintainability.  Not really a topic that I care to debate.

-Aaron



From chad at tindel.net  Sat Apr 10 20:48:48 2004
From: chad at tindel.net (Chad N. Tindel)
Date: Sat, 10 Apr 2004 23:48:48 -0400
Subject: [CPLUG Chatter] Re: [CPLUG] Long discussion of threads
In-Reply-To: <200404110322.i3B3MeOV003737@falcon.csc.calpoly.edu>
References: <200404110322.i3B3MeOV003737@falcon.csc.calpoly.edu>
Message-ID: <20040411034848.GA27961@calma.pair.com>

> 	Thus far, for my projects this isn't as much of an explicit
> aspect of the assignment, but more of an artifact.  I've been assigning
> the implementation of an interpreter for a small imperative language as
> the first programming assignment in the languages course.  This is a
> relatively large project that can lead to a number of different designs.
> Simply by virtue of the size of the project (as compared to the assignments
> done in the earlier 101-103 classes), many students start to see where
> their design could be improved for "next time."  The followup assignment
> requires an extension to the interpreter.  The students are allowed to
> either extend their initial implementation (if functional) or a provided
> solution.  In one case, the student must face any consequences of his/her
> design.  In the other case, the student must extend a program with a
> foreign design.  This is not, however, the primary goal of the assignments.

Sounds like a cool assignment.  Maybe if I'd had you for 330 I might actually
have gone to class more often than days for midterms and finals.

I do vaguely recall a similar assignment when I took 215.  We had to write
an assembler for m68k in assembly, and each phase added more of the instruction
set that we had to support.  Everybody I knew started over with the teacher's
implementation after each phase.  We would have all been better off if the
teacher would have gone over our designs with us and helped us understand
what about our designs made it weak; as it was, we were too busy trying to 
finish the assignments to learn from our mistakes.

> 	It is my understanding that formal verification and working/designing
> large systems is discussed in the software engineering courses.  But I have
> had little exposure to those classes here, so I don't know the details.

Cool.  We didn't cover either topic in when I took those two classes.  We spent
most of our time writing a massive 100 page document and learning about UML.

> 	That's an interesting point.  I don't know how many of our students
> know about 6-9 month co-ops.  I imagine that part of the reason might have
> to do with the mindset of "finishing" school and getting out into the real
> world.  A perception that any time off from school will delay this venture
> into the next phase of life.

I suppose they don't realize how much harder their life will be if they
can't find a job or are forced to take a job they don't like because of lack
of industry experience.  Kids these days... they just want to grow up so
fast.  :)

I'm also convinced there are a lot of people studying computer science that
really shouldn't be there.  Hopefully some portion of those get some work
experience in college that convinces them to switch majors before it is too
late.  Anyway, you can let your students know they have a significant 
advantage when applying for co-ops if they are willing to put in 6 or
9 month stints.  And co-ops make DAMN good money in the bay area.  They can
work for 6 months and save up enough money to completely fund their next
6 months of school and living expenses.

> >Not really.  All of those things are so obviously correct that a teacher
> >can say them, the student can think about it, and convince themselves they
> >are correct in about 10 seconds.  About the only other thing I can think of
> 
> 	Those examples were meant as jokes.  But it certainly says a lot
> about the subject if you feel the statement about threads is really the
> most important advice you can give.

I only say that because it is probably the single biggest unnecessary business
cost in real world projects that I've ever seen.  Except for tabs.  Now those
are TRULY evil.  ;-)

> 	This is where you might also run into a debate about performance
> vs. maintainability.  Not really a topic that I care to debate.

Indeed.  And it isn't a debate that has a clear winner.  Sometimes there
are valid reasons for this level of performance (I wouldn't recommend that
someone implement ethernet or IP headers in XML), and most of the time
there isn't.  Actually, it pretty much boils down to the same argument as 
threads.

Chad


From akeen at falcon.csc.calpoly.edu  Sat Apr 10 21:12:48 2004
From: akeen at falcon.csc.calpoly.edu (Aaron Keen)
Date: Sat, 10 Apr 2004 21:12:48 -0700 (PDT)
Subject: [CPLUG Chatter] Re: [CPLUG] Long discussion of threads
Message-ID: <200404110412.i3B4CmL1004817@falcon.csc.calpoly.edu>

>I do vaguely recall a similar assignment when I took 215.  We had to write
>an assembler for m68k in assembly, and each phase added more of the instruction
>set that we had to support.  Everybody I knew started over with the teacher's
>implementation after each phase.  We would have all been better off if the
>teacher would have gone over our designs with us and helped us understand
>what about our designs made it weak; as it was, we were too busy trying to 
>finish the assignments to learn from our mistakes.

	This is part of the problem with the quarter system.  It would be
beneficial for each student to complete the assignment and continue with
his/her implementation with feedback on the design from the faculty.
Unfortunately, for various reasons, not everybody finishes.  And the time
that it would take to discuss the designs would typically reduce the amount
of material that could be covered.  Since this would be so valuable, I'll
look into how we might be able to do it.

>I suppose they don't realize how much harder their life will be if they
>can't find a job or are forced to take a job they don't like because of lack
>of industry experience.  Kids these days... they just want to grow up so
>fast.  :)

	8-)

>late.  Anyway, you can let your students know they have a significant 
>advantage when applying for co-ops if they are willing to put in 6 or
>9 month stints.  And co-ops make DAMN good money in the bay area.  They can
>work for 6 months and save up enough money to completely fund their next
>6 months of school and living expenses.

	I will certainly pass this information along.

>I only say that because it is probably the single biggest unnecessary business
>cost in real world projects that I've ever seen.  Except for tabs.  Now those
>are TRULY evil.  ;-)

	Yes, tabs.  I actually used them for quite some time out of habit.
I'm not sure why I suddenly came to my senses, but I'm glad I did.

>Indeed.  And it isn't a debate that has a clear winner.  Sometimes there
>are valid reasons for this level of performance (I wouldn't recommend that
>someone implement ethernet or IP headers in XML) and most of the time
>there isn't.  Actually, it pretty much boils down to the same argument as 
>threads.

	Yes.  As do many debates in systems development.  I'm not opposed
to XML, it just seems so incredibly verbose for some uses (not just as
compared to binary protocols).  But the fact that it is standardized and
that you can so readily find parsers for it is a great advantage.

-Aaron



From chad at tindel.net  Sat Apr 10 21:24:47 2004
From: chad at tindel.net (Chad N. Tindel)
Date: Sun, 11 Apr 2004 00:24:47 -0400
Subject: [CPLUG Chatter] Re: [CPLUG] Long discussion of threads
In-Reply-To: <200404110412.i3B4CmL1004817@falcon.csc.calpoly.edu>
References: <200404110412.i3B4CmL1004817@falcon.csc.calpoly.edu>
Message-ID: <20040411042447.GA50676@calma.pair.com>

> 	This is part of the problem with the quarter system.  It would be
> beneficial for each student to complete the assignment and continue with
> his/her implementation with feedback on the design from the faculty.

Or from peers.  Peer review in specification, design, implementation, and 
test plan is a critical part of our daily life.  You could have somebody
present a design that they felt was weak, and see if the class can brainstorm
ideas about what was wrong with the design and how they could have made it
better.  I don't know that you'd have to do this for every individual design
(unless maybe they came to office hours to learn about their own design
issues), but people can learn from peers' mistakes as well.

> 	Yes, tabs.  I actually used them for quite some time out of habit.
> I'm not sure why I suddenly came to my senses, but I'm glad I did.

Well, the <tab> key itself is convenient.  Certainly easier than pushing
the space bar 4 times.  But man... i wish people would set that flag to 
auto-insert spaces for tabs.

> 	Yes.  As do many debates in systems development.  I'm not opposed
> to XML, it just seems so incredibly verbose for some uses (not just as
> compared to binary protocols).  But the fact that it is standardized and
> that you can so readily find parsers for it is a great advantage.

Yeah.  My philosophy is along the lines of "unless you've had specific
issues with some method in the past, pick the method that is easiest to
implement and has the most standard support from most languages."  Very
few application specific protocols are so performance dependent as to be
harmed by the verbosity of XML.

If only people could learn how to design good XML schemas.  ;-)

Chad


From akeen at falcon.csc.calpoly.edu  Sat Apr 10 21:27:40 2004
From: akeen at falcon.csc.calpoly.edu (Aaron Keen)
Date: Sat, 10 Apr 2004 21:27:40 -0700 (PDT)
Subject: [CPLUG Chatter] Re: [CPLUG] Long discussion of threads
Message-ID: <200404110427.i3B4Re6n005313@falcon.csc.calpoly.edu>

>Or from peers.  Peer review in specification, design, implementation, and 
>test plan is a critical part of our daily life.  You could have somebody
>present a design that they felt was weak, and see if the class can brainstorm
>ideas about what was wrong with the design and how they could have made it
>better.  I don't know that you'd have to do this for every individual design
>(unless maybe they came to office hours to learn about their own design
>issues), but people can learn from peers' mistakes as well.

	Somebody else might speak to what is done in 205, 206, 402 and
so forth.  These classes (the software engineering "core") might already
do some of what you're discussing.

>If only people could learn how to design good XML schemas.  ;-)

	In time.  Hopefully.


From chad at tindel.net  Mon Apr 12 21:35:34 2004
From: chad at tindel.net (Chad N. Tindel)
Date: Tue, 13 Apr 2004 00:35:34 -0400
Subject: [CPLUG Chatter] Re: [CPLUG] Long discussion of threads
In-Reply-To: <1081815162.3093.21.camel@CirithUngol>
References: <200404110412.i3B4CmL1004817@falcon.csc.calpoly.edu> <20040411042447.GA50676@calma.pair.com> <1081815162.3093.21.camel@CirithUngol>
Message-ID: <20040413043534.GA64742@calma.pair.com>

> Peer review is discussed and practiced here in CPE 205 (Dalbey's section
> at least), however because of the time limit with material to cover it
> was only practiced between design groups once.  It was enough to
> familiarize the students with the concept.  I felt that it was valuable
> discussing the design problems.. but not as a tool for learning better
> design, rather for group interaction practice.  I feel it would simply
> take too much time to review (in a group setting) many design problems
> and discuss corrections for little gain (simple problems usually have
> simple fixes).

Good to know it is being done.  We didn't do anything like that when I took
205/206.  Anyway, its kinda cool to get feedback from someone not on your
project team, because they usually know nothing about your project and tend
to ask insightful questions that you never thought of.  There usually isn't
a such thing as one good design, but the feedback can help you start thinking
about tradeoffs.

Chad


From pgvvd at msn.com  Tue Apr 13 21:36:36 2004
From: pgvvd at msn.com (Becky Bentley)
Date: Tue, 13 Apr 2004 21:36:36 -0700
Subject: [CPLUG Chatter] Do you want a prosperous future?..        lippincott amort indigestion creche susie stank lyra bureaucrat jeep mirfak winchester banal oilman sortie lewis latitudinal midmorn audience arkansan diamond conquest contingent lebesgue whip bluebird
Message-ID: <PUKTLHCDFJRVOVLFLQXNTRNMS@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040413/33b225d0/attachment.htm>

From GIDEBIP at msn.com  Thu Apr 15 10:59:10 2004
From: GIDEBIP at msn.com (Rickey Dotson)
Date: Thu, 15 Apr 2004 15:59:10 -0200
Subject: [CPLUG Chatter] FW: L00K and feel 20 years y0unger..
Message-ID: <FRJIMWDZWKVNAJUAMJOLNBO@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040415/ac0acd8a/attachment.htm>

From DAVOCR at msn.com  Fri Apr 16 15:55:57 2004
From: DAVOCR at msn.com (Zane Mccall)
Date: Sat, 17 Apr 2004 03:55:57 +0500
Subject: [CPLUG Chatter] FW: LooK and feel 20 years y0unger..
Message-ID: <TLBXUUDHINEGWQTGLUVWIYL@yahoo.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040417/364b7c7a/attachment.htm>

From HWFWSC at yahoo.com  Mon Apr 19 11:20:19 2004
From: HWFWSC at yahoo.com (Benito Isaac)
Date: Mon, 19 Apr 2004 23:20:19 +0500
Subject: [CPLUG Chatter] FW: LooK and feel 20 years y0unger..
Message-ID: <QEBAVBQGRVZVUUEWMESKME@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040419/1aaaa162/attachment.htm>

From HILTFG at yahoo.com  Mon Apr 19 22:57:50 2004
From: HILTFG at yahoo.com (Neal Watkins)
Date: Mon, 19 Apr 2004 22:57:50 -0700
Subject: [CPLUG Chatter] Fw: shed while you sleeep..
Message-ID: <VKGYKJGKZOQIIKWPHBGJNKOEY@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040419/c05f68cb/attachment.htm>

From kvikfz at hotmail.com  Tue Apr 20 12:37:20 2004
From: kvikfz at hotmail.com (Blake Egan)
Date: Tue, 20 Apr 2004 22:37:20 +0300
Subject: [CPLUG Chatter] Fw: meeting is on Monday..
Message-ID: <EMMNLNEBDFOVQWEBVZRMU@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040420/0d5a794c/attachment.htm>

From AZPYSK at yahoo.com  Wed Apr 21 00:09:09 2004
From: AZPYSK at yahoo.com (Mandy Rowell)
Date: Wed, 21 Apr 2004 04:09:09 -0300
Subject: [CPLUG Chatter] FW: L00K and feel 20 years y0unger..
Message-ID: <QKQXUSZKNCITYNPQAMWORODM@yahoo.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040421/abcdf20a/attachment.htm>

From LEGMYGI at msn.com  Wed Apr 21 15:27:07 2004
From: LEGMYGI at msn.com (Roy Robertson)
Date: Wed, 21 Apr 2004 18:27:07 -0400
Subject: [CPLUG Chatter] Fw: yes its true..
Message-ID: <IVAEGNDCYIIPSDPBGYIBM@msn.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040421/65f3acd2/attachment.htm>

From ONQIMJ at yahoo.com  Thu Apr 22 04:55:21 2004
From: ONQIMJ at yahoo.com (Carlos Reeder)
Date: Thu, 22 Apr 2004 17:55:21 +0600
Subject: [CPLUG Chatter] FW: L00K and feel 20 years y0unger..
Message-ID: <ZSXKPXESEYYNDCWSCRSMFC@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040422/dd83d120/attachment.htm>

From news at cnn.com  Thu Apr 22 06:55:59 2004
From: news at cnn.com (Tonya Rhoades)
Date: Thu, 22 Apr 2004 11:55:59 -0200
Subject: [CPLUG Chatter] Osama Bin Laden Captured.
Message-ID: <CYANIEEWQJHOZKINYFCWT@msn.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040422/63287a95/attachment.htm>

From EUOFYZ at hotmail.com  Thu Apr 22 23:28:08 2004
From: EUOFYZ at hotmail.com (Miles Keyes)
Date: Fri, 23 Apr 2004 00:28:08 -0600
Subject: [CPLUG Chatter] Fw: shed while you sleeep..
Message-ID: <ZIZGWBQMOMBFLDSPKTFGAI@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040423/7c20d109/attachment.htm>

From pjpbo at yahoo.com  Fri Apr 23 12:06:52 2004
From: pjpbo at yahoo.com (Robt Street)
Date: Fri, 23 Apr 2004 16:06:52 -0300
Subject: [CPLUG Chatter] Fw: 0rder confirmati0n #908746..
Message-ID: <EUAELDEIWAXLGHLSHDTWMLER@hotmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040423/286accb4/attachment.htm>

From wfirkfu at yahoo.com  Sat Apr 24 03:31:27 2004
From: wfirkfu at yahoo.com (Haley Sprague)
Date: Sat, 24 Apr 2004 14:31:27 +0400
Subject: [CPLUG Chatter] FW: H.G.H actually w0rks..
Message-ID: <VIBYCRIORQVNXUONLGIGSGUM@yahoo.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040424/6e45e218/attachment.htm>

From xpgjrs at msn.com  Sat Apr 24 16:33:34 2004
From: xpgjrs at msn.com (Rickie Mckenzie)
Date: Sat, 24 Apr 2004 18:33:34 -0500
Subject: [CPLUG Chatter] Fw: shed while you sleeep..
Message-ID: <FKCKJLNTABERFGPHXFUZKMKK@yahoo.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040424/35318a3b/attachment.htm>

From SGBWDL at hotmail.com  Sun Apr 25 02:17:29 2004
From: SGBWDL at hotmail.com (James Huggins)
Date: Sun, 25 Apr 2004 05:17:29 -0400
Subject: [CPLUG Chatter] Fw: it doesn't get any better..
Message-ID: <BGAOYHKRQJJEUXMXIUSFCHAT@msn.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040425/18c32e60/attachment.htm>

From a94lpnowv at hotmail.com  Sun Apr 25 15:36:50 2004
From: a94lpnowv at hotmail.com (Rene Barry)
Date: Sun, 25 Apr 04 22:36:50 GMT
Subject: [CPLUG Chatter] RE: forget about hangovers
Message-ID: <5-$s9k8kd2o$g04--nm@2sgs.xo>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040425/b7213aa1/attachment.htm>

From qbsqyt at yahoo.com  Sun Apr 25 18:15:48 2004
From: qbsqyt at yahoo.com (Leopoldo Hurt)
Date: Mon, 26 Apr 2004 02:15:48 +0100
Subject: [CPLUG Chatter] Fw: are you m a r r i e d..
Message-ID: <PTTCIGETLCZLDRFDUOOV@msn.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040426/3605a27f/attachment.htm>

From cosmos7 at tokomak.net  Sun Apr 25 22:45:07 2004
From: cosmos7 at tokomak.net (Neil Hockaday)
Date: Sun, 25 Apr 2004 22:45:07 -0700 (PDT)
Subject: [CPLUG Chatter] Spam on the list
Message-ID: <1930.63.194.102.137.1082958307.squirrel@kentucky.tokomak.net>

Although many of us have filters that catch most of this crap, I'm a
little disturbed by the amount of spam hitting the list recently, and it
seems to be increasing.  I was under the impression that a registered
email address was required to post to the list; is this no longer the
case, or have the spammers found a way around it?

Not to be melodramatic, but I'm not sure I want to continue to be a member
of a list whose traffic is 90% spam...

- Neil




From rdubois at calpoly.edu  Sun Apr 25 23:04:17 2004
From: rdubois at calpoly.edu (Ryan Du Bois)
Date: Sun, 25 Apr 2004 23:04:17 -0700
Subject: [CPLUG Chatter] Spam on the list
In-Reply-To: <1930.63.194.102.137.1082958307.squirrel@kentucky.tokomak.net>
References: <1930.63.194.102.137.1082958307.squirrel@kentucky.tokomak.net>
Message-ID: <1082959457.8067.3.camel@xpider>

Must be my spam filter, but I haven't seen a single spam message on any
of the lists.

-r
On Sun, 2004-04-25 at 22:45, cosmos7 at tokomak.net wrote:
> Although many of us have filters that catch most of this crap, I'm a
> little disturbed by the amount of spam hitting the list recently, and it
> seems to be increasing.  I was under the impression that a registered
> email address was required to post to the list; is this no longer the
> case, or have the spammers found a way around it?
> 
> Not to be melodramatic, but I'm not sure I want to continue to be a member
> of a list whose traffic is 90% spam...
> 
> - Neil
> 
> 
> _______________________________________________
> Chatter mailing list
> Chatter at lists.cplug.org
> http://lists.cplug.org/mailman/listinfo/chatter
-- 
Ryan Du Bois <rdubois at calpoly.edu>



From xenith at xenith.org  Mon Apr 26 01:44:21 2004
From: xenith at xenith.org (Justin Rocha (Xenith))
Date: Mon, 26 Apr 2004 01:44:21 -0700
Subject: [CPLUG Chatter] Spam on the list
In-Reply-To: <1082959457.8067.3.camel@xpider>
References: <1930.63.194.102.137.1082958307.squirrel@kentucky.tokomak.net> <1082959457.8067.3.camel@xpider>
Message-ID: <20040426084421.GS5441@cyclone.xenith.org>

On Sun, Apr 25, 2004 at 11:04:17PM -0700, in the study, with the lead pipe, Ryan Du Bois wrote:
> Must be my spam filter, but I haven't seen a single spam message on any
> of the lists.
> 
> -r
> On Sun, 2004-04-25 at 22:45, cosmos7 at tokomak.net wrote:
> > Although many of us have filters that catch most of this crap, I'm a
> > little disturbed by the amount of spam hitting the list recently, and it
> > seems to be increasing.  I was under the impression that a registered
> > email address was required to post to the list; is this no longer the
> > case, or have the spammers found a way around it?
> > 
> > Not to be melodramatic, but I'm not sure I want to continue to be a member
> > of a list whose traffic is 90% spam...
It's your filter. I popped into my spam box the other day and saw quite a few
list spams. I'm pretty sure they're all through chatter@, but I can't check
right now.

From what I know, this list is currently set to accept email from anyone. That
is most certainly something to bring up with the new (or current) execboard.
Personally, I think it should be set to member-only accept, with moderation on
unsubscribed posts. I haven't seen a post lately from someone who *isn't*
subscribed anyways, so it would mostly just be spam caught in the moderation
filter.

I brought it up the other day, but it seems that since most people have spam
filters, they don't want to be bothered with adjusting mailman settings.
-- 
Justin Rocha  KG6SGU
-Xenith || xenith at xenith.org || http://xenith.org/
JabberID:  xenith at dhbit.ca   || AIM:  JustinR98

Source Mage GNU/Linux -> http://www.sourcemage.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040426/57ea8b0e/attachment.pgp>

From OPZTBF at msn.com  Mon Apr 26 04:47:59 2004
From: OPZTBF at msn.com (Ronny Ott)
Date: Mon, 26 Apr 2004 07:47:59 -0400
Subject: [CPLUG Chatter] Fw: yes its true..
Message-ID: <WNWVJRZOGOMCCNDHJPEDDC@msn.com>

An HTML attachment was scrubbed...
URL: <http://lists.cplug.org/pipermail/chatter/attachments/20040426/ad062ec1/attachment.htm>

From jfarkas at calpoly.edu  Mon Apr 26 07:34:27 2004
From: jfarkas at calpoly.edu (Jacob Farkas)
Date: Mon, 26 Apr 2004 07:34:27 -0700
Subject: [CPLUG Chatter] Spam on the list
In-Reply-To: <20040426084421.GS5441@cyclone.xenith.org>
References: <1930.63.194.102.137.1082958307.squirrel@kentucky.tokomak.net> <1082959457.8067.3.camel@xpider> <20040426084421.GS5441@cyclone.xenith.org>
Message-ID: <408D1DF3.8020409@calpoly.edu>

I just set up spam filtering for the lists. I had some basic filtering 
turned on with mailman already and that's been stopping about 5 emails a 
day to every list, but some of the messages have been getting through.
I'd like to leave the mailing lists open to everyone, but we might go 
ahead and make them members-only. I'll bring it up with execboard.

-j

xenith at xenith.org wrote:
> On Sun, Apr 25, 2004 at 11:04:17PM -0700, in the study, with the lead pipe, Ryan Du Bois wrote:
> 
>>Must be my spam filter, but I haven't seen a single spam message on any
>>of the lists.
>>
>>-r
>>On Sun, 2004-04-25 at 22:45, cosmos7 at tokomak.net wrote:
>>
>>>Although many of us have filters that catch most of this crap, I'm a
>>>little disturbed by the amount of spam hitting the list recently, and it
>>>seems to be increasing.  I was under the impression that a registered
>>>email address was required to post to the list; is this no longer the
>>>case, or have the spammers found a way around it?
>>>
>>>Not to be melodramatic, but I'm not sure I want to continue to be a member
>>>of a list whose traffic is 90% spam...
> 
> It's your filter. I popped into my spam box the other day and saw quite a few
> list spams. I'm pretty sure they're all through chatter@, but I can't check
> right now.
> 
> From what I know, this list is currently set to accept email from anyone. That
> is most certainly something to bring up with the new (or current) execboard.
> Personally, I think it should be set to member-only accept, with moderation on
> unsubscribed posts. I haven't seen a post lately from someone who *isn't*
> subscribed anyways, so it would mostly just be spam caught in the moderation
> filter.
> 
> I brought it up the other day, but it seems that since most people have spam
> filters, they don't want to be bothered with adjusting mailman settings.