[Ab]use of penderel

[Jonathan Peterson]

Is one allowed to run very small low traffic mailing lists from 
penderel? Come to that are there any FAQs guidelines on use of your 
trusty penderel account?

Thanks,

Jon

Re: [Ab]use of penderel

[Mark Fowler]

On Mon, 2 Jun 2003, Jonathan Peterson wrote:

> Is one allowed to run very small low traffic mailing lists from
> penderel? Come to that are there any FAQs guidelines on use of your
> trusty penderel account?

I think I've suggested that all things penderel like should be evalutated
on a case by case basis.

What's the mailing list for?

Also, bear in mind that I've made public commitments in the past to moving
penderel over to siesta when it's ready.  Be prepared for mailman to go
bye bye at some point, even if it technically possible to run them at the
same time.

Mark.

-- 
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};

Re: [Ab]use of penderel

[Jonathan Peterson]

I think I've suggested that all things penderel like should be evalutated
on a case by case basis.
What's the mailing list for?
 

It's for members of an investment club to talk to each other. It's like 
10 people and about the same num of messages per week.

Also, bear in mind that I've made public commitments in the past to moving
penderel over to siesta when it's ready.  Be prepared for mailman to go
bye bye at some point, even if it technically possible to run them at the
same time.
I was thinking along the lines of  a .forward file or a bit of procmail 
or something :-) Although if Siesta's in a useable state (and doesn't 
require root to run it) I'm happy to plonk a copy in my home dir and 
play with it.

It's more the principle of the thing I was checking...

Jon




Mark.

 

Re: URL wierdness...

[Andy Williams \(IMAP HILLWAY\)]

- Original Message - 
From: "Jody Belka" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 02, 2003 2:29 PM
Subject: Re: URL wierdness...


> IMAP HILLWAY\ said:
> >
> > Now... this works fine for almost every URL I can think of apart from 2:
> > http://www.acxiom.co.uk & http://www.acxiom.com
> > These 2 both return "500 Internal Server Error" but work fine if you go
> > to them with a browser!
>
> bit of checking and it seems that they're using the Accept-Language
> header, and don't imagine you might not send it. if you add that to the
> request (a simple en or en-us will do the trick) then things work
> properly. really bad form on their side of course.
>
> Jody


Thanks Jody.

That did the trick new code is:


use LWP::UserAgent;
use HTTP::Request;
use HTTP::Request::Common;

my $browser;
my $ua = new LWP::UserAgent;
$ua->agent('Mozilla/5.0');
$ua->timeout(15);
my $url = 'http://www.acxiom.co.uk';
my $req = new HTTP::Request;
my $res = $ua->request(GET $url, 'Accept-Language' => 'en');

Re: [JOB] (maybe) Leicester

[Piers Cawley]

Chris Benson <[EMAIL PROTECTED]> writes:

> On Sun, Jun 01, 2003 at 06:33:59AM +0100, Piers Cawley wrote:
>> 
>> Well, I might have been not that long ago, but I've got a month in
>> America coming up after which we're probably moving to Newcastle. So
>> that doesn't really help all that much does it?
>
> Tyneside.pm ++ ?

Well, it's contingent on a few things, but it's looking likely.

-- 
Piers

Re: [Ab]use of penderel

[Paul Makepeace]

On Mon, Jun 02, 2003 at 04:14:23PM +0100, Mark Fowler wrote:
> Also, bear in mind that I've made public commitments in the past to moving
> penderel over to siesta when it's ready.  Be prepared for mailman to go
> bye bye at some point, even if it technically possible to run them at the
> same time.

This might be an offlist sysadmin discussion but is there some
(rational) reason to uninstall some software that works, simply because
another piece of software can do something similar? Should we uninstall
python and ruby from penderel as well? Uninstall dc because you can do
maths in perl?

Paul

-- 
Paul Makepeace ... http://paulm.com/

"If laughter can heal, then the would would be polluted by crazy poop."
   -- http://paulm.com/toys/surrealism/

Re: [Ab]use of penderel

[Paul Makepeace]

On Mon, Jun 02, 2003 at 10:01:53PM +0100, Michael Stevens wrote:
> On Mon, Jun 02, 2003 at 09:41:14PM +0100, Paul Makepeace wrote:
> > On Mon, Jun 02, 2003 at 04:14:23PM +0100, Mark Fowler wrote:
> > > Also, bear in mind that I've made public commitments in the past to moving
> > > penderel over to siesta when it's ready.  Be prepared for mailman to go
> > > bye bye at some point, even if it technically possible to run them at the
> > > same time.
> > 
> > This might be an offlist sysadmin discussion but is there some
> > (rational) reason to uninstall some software that works, simply because
> > another piece of software can do something similar? Should we uninstall
> > python and ruby from penderel as well? Uninstall dc because you can do
> > maths in perl?
> 
> I think in the special case where you actually write the software, it
> looks odd if you don't use it. I'm generalising here to assuming
> london.pm is collectively writing siesta, rather than it being the hard
> work of a few members, as it actually is.

I'm making the distinction between using another piece of software
(which you're advocating with sound reasons) and actually *un*installing
an existing, known working, mature piece of software others might wish
to use. Generalising, it is in effect making verboten any *class* of
software that has an instance authored by someone in London.pm.
Penderel/London.pm in my mind is an inclusive system, and this to my
mind is counter to that. I'm sure Mark will clarify here.

It's more a point of principle operating a shared resource than wrt any
discussion/merits of particular MLM/London.pm-specific development.

Paul

-- 
Paul Makepeace ... http://paulm.com/

"If kitten whiskers were three feet long, then why does he look at me
 with those shoe-tying eyes."
   -- http://paulm.com/toys/surrealism/

Re: [Ab]use of penderel

[the hatter]

On Mon, 2 Jun 2003, Paul Makepeace wrote:

> This might be an offlist sysadmin discussion but is there some
> (rational) reason to uninstall some software that works, simply because
> another piece of software can do something similar?

One less think to think about and patch ?  I wouldn't be hugely convinced
by the argument in this case, it's not like an MTA that can only have one
thing run on one port, and it cooperates fairly trivially with any other
web server.

> Should we uninstall python and ruby from penderel as well? Uninstall dc
> because you can do maths in perl?

That'd be handy.  With mailman gone, I'm sure no one will need python any
more, anyway.  We can get also get rid of sed/awk/grep/etc.  Except all of
those which gnu configure and make require to actually make perl,
obviously.


the hatter

Re: [Ab]use of penderel

[Mark Fowler]

On Mon, 2 Jun 2003, Paul Makepeace wrote:

> I'm making the distinction between using another piece of software
> (which you're advocating with sound reasons) and actually *un*installing
> an existing, known working, mature piece of software others might wish
> to use.

I was mearly implying that mailman would move from being something that is
very activly supported (as it is now) to something that probably won't be
looked after as much.

In future I shall not bother warning people, less someone jumps down my
throat.

Mark.

-- 
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};

Re: [Ab]use of penderel

[Nicholas Clark]

Am I correct in remembering Paul has root on penderel?

On Mon, Jun 02, 2003 at 10:22:17PM +0100, Paul Makepeace wrote:
> On Mon, Jun 02, 2003 at 10:01:53PM +0100, Michael Stevens wrote:
> > On Mon, Jun 02, 2003 at 09:41:14PM +0100, Paul Makepeace wrote:
> > > On Mon, Jun 02, 2003 at 04:14:23PM +0100, Mark Fowler wrote:
> > > > Also, bear in mind that I've made public commitments in the past to moving
> > > > penderel over to siesta when it's ready.  Be prepared for mailman to go
> > > > bye bye at some point, even if it technically possible to run them at the
> > > > same time.

> I'm making the distinction between using another piece of software
> (which you're advocating with sound reasons) and actually *un*installing
> an existing, known working, mature piece of software others might wish
> to use. Generalising, it is in effect making verboten any *class* of
> software that has an instance authored by someone in London.pm.
> Penderel/London.pm in my mind is an inclusive system, and this to my
> mind is counter to that. I'm sure Mark will clarify here.
> 
> It's more a point of principle operating a shared resource than wrt any
> discussion/merits of particular MLM/London.pm-specific development.

In my opinion I don't think what Mark said is counter to Penderel being an
inclusive system.  "mailing list software" will continue to be provided -
it's just that it is forseen that in the near future the preferred mailing
list software will switch from mailman to siesta.

Whilst that doesn't cause mailman to become broken (as you point out), it
does mean that now two mailing list systems are being supported. Whilst that
support may be zero effort most of the time, as we all know the discovery of
security holes in software can overnight turn working software into "broken"
(at least, something needing active maintenance), particularly for an
outward facing service such as a mailing list. Hence to me it seems
prudent to encourage users to migrate over to siesta, so that mailman
could be removed, reducing the number of external security risks.

Nicholas Clark

Re: [Ab]use of penderel

[Paul Makepeace]

On Mon, Jun 02, 2003 at 10:57:37PM +0100, Mark Fowler wrote:
>>> Be prepared for mailman to go bye bye at some point, even if it
>>> technically possible to run them at the same time.

> I was mearly implying that mailman would move from being something that is
> very activly supported (as it is now) to something that probably won't be
> looked after as much.

Cool; I got a different message from something "going bye bye" and the
implication of the rest.

> In future I shall not bother warning people, less someone jumps down my
> throat.

There's obviously a difference between telling people you are simply not
personally supporting software and actually uninstalling it.

Did you perceive what I said as "jumping down your throat"? It wasn't
intended as that; it was intended to clarify a position on list in
public that might have consequences for users of penderel down the line.
Sorry that wasn't so clear.

Paul

-- 
Paul Makepeace ... http://paulm.com/

"What is the best way to tell your dad you're gay? 22 Trombones."
   -- http://paulm.com/toys/surrealism/

Re: [Ab]use of penderel

[the hatter]

On Mon, 2 Jun 2003, Mark Fowler wrote:

> In future I shall not bother warning people, less someone jumps down my
> throat.

Excellent, it'll be an even more enchanting surprise for everyone when all
the other shells are pulled, and we all start using the perl shell.

Vaguely more on-topic though, I disn't read it as anyone jumping down your
throat, just wanting to get a better idea of how the minds that massage
penedrel do their stuff.


the hatter

Re: Reaping process...

[Dirk Koopman]

On Mon, 2003-06-02 at 11:48, Nigel Hamilton wrote:
> > 
> > In what way are you limiting the total number of processes?
> > 
> 
> I´ve just implemented a pre-forking server so it is limited to the number 
> of pre-forked servers * 10 forks per server - this has improved things a 
> bit.
> 
> > You probably know anyway, but remember that 20 processes that operate without
> > swapping will be way more than twice as fast to finish as 40 processes that
> > run out of memory and swap. So, limit your processes to the machine's
> > capabilities.
> 
> Yep ... I'm fast finding out my machine's limits ... :-) ... I'm
> dynamically checking the load so the search box doesn't come up if the
> system load exceeds a certain threshold - thanks here to Randal Schwartz'
> poor man´s load balancing ideas and the CPAN module -> Sys::Load.
> 
> But the performance of the forking miniserver is a worry - I've 
> implemented a preforking version and although this is better the server 
> still melts.
> 
> Previously I've implemented this component using Java threads and I also 
> considered Java non-blocking IO but the performance was not as good as 
> perl fork()ed processes - so I gladly reverted to Perl.

I hate to say this but, frankly, this is not (imho) a pure perl
application. I have spent quite a bit of time fiddling around with perl
as webserver type thing and done some benchmarks. 

Basically, a pure perl webserver using optimised CPAN modules just
serving static pages (on a 600Mhz P-III) manages about 200 hits / sec on
10K pages (standard modules about half that), apache manages about
1500-2000 hits / sec. 

A lot of this has to do with physical reading of a HTTP request. If you
delve inside the modules you will see a lot of, what amounts to, copying
whilst it is building up the HTTP request. It all seems to be very slow.
I do wonder whether you should be considering, very carefully, where you
really need perl and also if you can actually do it in C. Remember that
there is the excellent pcre regex engine which stitches in nicely to C
programs. 

An optimised mod_perl/apache (1.3) setup should be faster and will
handle your forking problems for you. Writing mod_perl to stitch into
apache is actually not very hard at all [you just need to transliterate
the jargon in normal perl speak], especially if you have a working pure
perl app already done.  

Stitching in a C app into apache would be even better

Dirk
-- 
Please Note: Some Quantum Physics Theories Suggest That When the
Consumer Is Not Directly Observing This Product, It May Cease to
Exist or Will Exist Only in a Vague and Undetermined State.

Re: [Ab]use of penderel

[Paul Makepeace]

On Mon, Jun 02, 2003 at 11:02:43PM +0100, Nicholas Clark wrote:
> Whilst that doesn't cause mailman to become broken (as you point out), it
> does mean that now two mailing list systems are being supported. Whilst that
> support may be zero effort most of the time, as we all know the discovery of

Just FYI & so everyone can sleep easily: thanks to a whole bunch of
people last year penderel, python, mailman, etc are under Debian's
standard package management. Patches are thus picked up automatically
during debian's usual upgrade/patch-issuing cycle. I have set up the
Debian security announcements to go to the (sadly underused, but at
least read) internal SysOps list so several people are informed as
Debian sends out security alerts.

I personally don't see operating a piece of software under Debian stable
as a significant risk, especially one that is not listening on a port,
on a machine whose data everyone *ahem* has back-ups of :-)

Paul

-- 
Paul Makepeace ... http://paulm.com/

"If this van's a rockin', then yes, I think I will."
   -- http://paulm.com/toys/surrealism/

Re: Reaping process...

[Dirk Koopman]

On Mon, 2003-06-02 at 23:27, Dirk Koopman wrote:
> > But the performance of the forking miniserver is a worry - I've 
> > implemented a preforking version and although this is better the server 
> > still melts.
> > 
> > Previously I've implemented this component using Java threads and I also 
> > considered Java non-blocking IO but the performance was not as good as 
> > perl fork()ed processes - so I gladly reverted to Perl.
> 
> I hate to say this but, frankly, this is not (imho) a pure perl
> application. I have spent quite a bit of time fiddling around with perl
> as webserver type thing and done some benchmarks. 
> 
> Basically, a pure perl webserver using optimised CPAN modules just
> serving static pages (on a 600Mhz P-III) manages about 200 hits / sec on
> 10K pages (standard modules about half that), apache manages about
> 1500-2000 hits / sec. 

and what I failed to add was that the pure perl version was CPU limited
and the apache server was IO limited. 

If you want to use pure perl you are going to have to load balance and
have several perl "app" processors to do your job...

Dirk
-- 
Please Note: Some Quantum Physics Theories Suggest That When the
Consumer Is Not Directly Observing This Product, It May Cease to
Exist or Will Exist Only in a Vague and Undetermined State.

Dotcom Boom History

[Dave Cross]

A while ago I had a discussion in a pub[1] with various london.pm
people about how it would be interesting to have a record of
people's memories of the Golden Age of the Dotcom Boom in London.
A few months ago I started a discussion about it on the list
(see ).

So anyway, I've finally done something about it. I've set up
a Wiki (driven by CGI::Kwiki which is extremely shiney!) as somewhere
to dump all of this information.

So if you have any information to share with the world, please
go to  and add your memories. I'm particularly
interested in:

* A timeline of events

* Histories of companies who were involved

* Groups of people (i.e. london.pm, void, haddock, etc)

* Key people who might have interesting anecdotes.

Oh, and please feel free to forward this email to anyone else
that might be interested (or interesting!)

Share & Enjoy,

Dave...

[1] And it must a have been a long while ago as I distinctly
remember drinking!
-- 


"Let me see you make decisions, without your television"
   - Depeche Mode (Stripped)

Re: Reaping process...

[Nigel Wetters]

Dirk Koopman wrote:
> I hate to say this but, frankly, this is not (imho) a pure perl
> application. I have spent quite a bit of time fiddling around with perl
> as webserver type thing and done some benchmarks. 

Me too!

I coded a few Perl implementations of the servers from Comer & Stevens
[0]. The experience was extremely frustrating as performance stank and
under high load zombies always became a problem, whatever reaping code I
used. I guess reaping is just fragile under high load.

There doesn't seem a sensible reason to code a web server in Perl. It's
going to be slower than apache and is likely to break under pressure.

--nwetters

[0] http://www.amazon.com/exec/obidos/ASIN/013260969X/

Re: [Ab]use of penderel

[Simon Wistow]

On Mon, Jun 02, 2003 at 09:53:08PM +, the hatter said:
> That'd be handy.  With mailman gone, I'm sure no one will need python any
> more, anyway.  We can get also get rid of sed/awk/grep/etc.  Except all of
> those which gnu configure and make require to actually make perl,
> obviously.

Ah pedantry, righteous indignation and hysterical extrapolation - all 
the great traits of mailing lists. [0]

I've only skimmed over this thread and, as a Siesta developer, I am 
obviously biased so please take my comments with a pinch of whatever 
your fancy is.

If I read it correctly Mark was suggesting moving london.pm to Siesta. 
Not removing Mailman. Or, in fact sed/awk/grep. Or even ls. Thus the sky 
will nto fall and locusts will not descend and devour our entrails.

The status of Siesta is currently -

* works fine as the MLM for its own mailing list
* is still being worked on
* has no web based interface

so clearly it's not ready *just* yet to be the MLM for london.pm

But, it maybe in the future.

Now obviously we wouldn't be writing it if we didn't think it would be 
better than Mailman (where better is loosely defined as "does things 
which we think are important which Mailman does not and which were 
easier to incorporate into a totally new MLM than patch Mailman").

Some good reasons for moving over to Siesta

o better support 
We are among you, we developers. Although Mailman support may have 
picked up again recently (I'm not sure, it used to be pretty terrible) 
we are almost certainly guaranteed to be even closer.  

o user configurable preferences 
I think this is the killer. No more whining from Randal about Reply-To 
munging - all he has to do is configure it not to munge for him. And if 
somebody hates supercite - then all you have to do is write a 
de-superciter et voila.

Other applications include marking up a section of text as a buffy 
spoiler and then write a plugin which will allow people to say they 
don't want to receive spoilers from seasons less than $n.

So basically the single most important thing about Siesta is that it 
stops people pissing and moaning - about the fact that a Perl mailing 
list is run on a Python MLM (not actually that big a deal for me), about 
missing features from Mailman, about reply to munging, or supercite or 
archive headers or a whole host of other things.

And I think we all agree that's a good thing. Less moaning equals more 
time for 8uffy, pie and beer.

-- BEGIN SHORT CONCLUSION --

For those that want the Cliff Notes version. 

So my reading is that Mailman is not going away and that, if l.pm ever 
moves to $other MLM you'll probably never even notice anyway.

-- END SHORT CONCLUSION --


Simon

[0] Not singling you out. I was just summing up all the good things 
about mailing lists.


--
les singe qui dansent

Re: Reaping process...

[alex]

> Me too!

and me:
http://www.twoshortplanks.com:

:-)

a

>
> I coded a few Perl implementations of the servers from Comer & Stevens
> [0]. The experience was extremely frustrating as performance stank and
> under high load zombies always became a problem, whatever reaping code I
> used. I guess reaping is just fragile under high load.
>
> There doesn't seem a sensible reason to code a web server in Perl. It's
> going to be slower than apache and is likely to break under pressure.
>
> --nwetters
>
> [0] http://www.amazon.com/exec/obidos/ASIN/013260969X/
>

Re: [Ab]use of penderel

[Mark Fowler]

On Mon, 2 Jun 2003, Paul Makepeace wrote:

> 

And lo, it was proved once again that email sucks, and misunderstandings
happen when people like me write badly worded emails (twice, in this
case.)  As I have stated many times before I is most defiantly crap.

Mark.

-- 
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};

Re: Dotcom Boom History

[Jonathan Peterson]

Damn. And I was going to do some work today, too...

Dave Cross wrote:

A while ago I had a discussion in a pub[1] with various london.pm
people about how it would be interesting to have a record of
people's memories of the Golden Age of the Dotcom Boom in London.
A few months ago I started a discussion about it on the list
(see ).
 

Re: Reaping process...

[Shevek]

On Tue, 3 Jun 2003, Nigel Wetters wrote:

> Dirk Koopman wrote:
> 
> I coded a few Perl implementations of the servers from Comer & Stevens
> [0]. The experience was extremely frustrating as performance stank and
> under high load zombies always became a problem, whatever reaping code I
> used. I guess reaping is just fragile under high load.

Ignore the SIGCHLD. POSIX only guarantees signal delivery within 4 
minutes. Just reap a few whenever you get to an appropriate point in your 
code.

S.

-- 
Shevekhttp://www.anarres.org/
I am the Borg. http://design.anarres.org/

Re: Reaping process...

[Toby Corkindale]

On Tue, Jun 03, 2003 at 12:32:41PM +0100, Shevek wrote:
> On Tue, 3 Jun 2003, Nigel Wetters wrote:
> 
> > Dirk Koopman wrote:
> > 
> > I coded a few Perl implementations of the servers from Comer & Stevens
> > [0]. The experience was extremely frustrating as performance stank and
> > under high load zombies always became a problem, whatever reaping code I
> > used. I guess reaping is just fragile under high load.
> 
> Ignore the SIGCHLD. POSIX only guarantees signal delivery within 4 
> minutes. Just reap a few whenever you get to an appropriate point in your 
> code.

Has anyone experimented with signal handling in linux threads in the 2.5
kernels? According to some stuff I've read, it behaves a lot better than
under 2.4, but I'm interested to know to what extent.

The 2.4 method of delivering signals to sometimes-one, sometimes-all,
sometimes-some threads was icky. I used to set a block on all signals, in all
threads, and then designate one thread to be a 'signal handler' and unblock
signals for it; but this didn't always work as expected.

This was 2.4.x kernels, and probably glibc 2.1.3, so I understand it may have
improved in later glibc editions?

tjc

Re: Reaping process...

[Dominic Mitchell]

Shevek wrote:
Ignore the SIGCHLD. POSIX only guarantees signal delivery within 4 
minutes. Just reap a few whenever you get to an appropriate point in your 
code.
This intrigues me enough to take a look.  Apparently, the POSIX docs are 
available online now:

 [uses frames]

I couldn't find the section that mentions this time limit though.  The 
closest I came was the "Signal Generation and Delivery" section:



Any ideas?

-Dom

--
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |

checking port status with perl

[Andy Ford]

Hi all

I am writing a Perl script to check the status of a number of processes
on a solaris machine i.e. to check mysqld I can use 

my $result = $dbh->ping;

Is there a perl module that will allow me to do something similar with
apache or sshd to see if they are running and accepting connections?


Thanks

-- 
Andy Ford <[EMAIL PROTECTED]>
Telindus

Re: checking port status with perl

[Shevek]

On Tue, 3 Jun 2003, Andy Ford wrote:

> Hi all
> 
> I am writing a Perl script to check the status of a number of processes
> on a solaris machine i.e. to check mysqld I can use 
> 
>   my $result = $dbh->ping;
> 
> Is there a perl module that will allow me to do something similar with
> apache or sshd to see if they are running and accepting connections?

Yes. Mon.

S.

-- 
Shevekhttp://www.anarres.org/
I am the Borg. http://design.anarres.org/

Re: checking port status with perl

[Roger Burton West]

On Tue, Jun 03, 2003 at 02:36:31PM +0100, Shevek wrote:
>On Tue, 3 Jun 2003, Andy Ford wrote:
>> Is there a perl module that will allow me to do something similar with
>> apache or sshd to see if they are running and accepting connections?
>Yes. Mon.

Or Thoth (which I obviously favour because I'm the principal author). Or
NOCOL (part-Perl). Or Netsaint (not at all Perl). Or...

Roger