Fri Mar 29 02:20:45 2024
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2020-12-01

HANGOUT

2024-03-29 | 2024-02-29 | 2024-01-29 | 2023-12-29 | 2023-11-29 | 2023-10-29 | 2023-09-29 | 2023-08-29 | 2023-07-29 | 2023-06-29 | 2023-05-29 | 2023-04-29 | 2023-03-29 | 2023-02-28 | 2023-01-28 | 2022-12-28 | 2022-11-28 | 2022-10-28 | 2022-09-28 | 2022-08-28 | 2022-07-28 | 2022-06-28 | 2022-05-28 | 2022-04-28 | 2022-03-28 | 2022-02-28 | 2022-01-28 | 2021-12-28 | 2021-11-28 | 2021-10-28 | 2021-09-28 | 2021-08-28 | 2021-07-28 | 2021-06-28 | 2021-05-28 | 2021-04-28 | 2021-03-28 | 2021-02-28 | 2021-01-28 | 2020-12-28 | 2020-11-28 | 2020-10-28 | 2020-09-28 | 2020-08-28 | 2020-07-28 | 2020-06-28 | 2020-05-28 | 2020-04-28 | 2020-03-28 | 2020-02-28 | 2020-01-28 | 2019-12-28 | 2019-11-28 | 2019-10-28 | 2019-09-28 | 2019-08-28 | 2019-07-28 | 2019-06-28 | 2019-05-28 | 2019-04-28 | 2019-03-28 | 2019-02-28 | 2019-01-28 | 2018-12-28 | 2018-11-28 | 2018-10-28 | 2018-09-28 | 2018-08-28 | 2018-07-28 | 2018-06-28 | 2018-05-28 | 2018-04-28 | 2018-03-28 | 2018-02-28 | 2018-01-28 | 2017-12-28 | 2017-11-28 | 2017-10-28 | 2017-09-28 | 2017-08-28 | 2017-07-28 | 2017-06-28 | 2017-05-28 | 2017-04-28 | 2017-03-28 | 2017-02-28 | 2017-01-28 | 2016-12-28 | 2016-11-28 | 2016-10-28 | 2016-09-28 | 2016-08-28 | 2016-07-28 | 2016-06-28 | 2016-05-28 | 2016-04-28 | 2016-03-28 | 2016-02-28 | 2016-01-28 | 2015-12-28 | 2015-11-28 | 2015-10-28 | 2015-09-28 | 2015-08-28 | 2015-07-28 | 2015-06-28 | 2015-05-28 | 2015-04-28 | 2015-03-28 | 2015-02-28 | 2015-01-28 | 2014-12-28 | 2014-11-28 | 2014-10-28 | 2014-09-28 | 2014-08-28 | 2014-07-28 | 2014-06-28 | 2014-05-28 | 2014-04-28 | 2014-03-28 | 2014-02-28 | 2014-01-28 | 2013-12-28 | 2013-11-28 | 2013-10-28 | 2013-09-28 | 2013-08-28 | 2013-07-28 | 2013-06-28 | 2013-05-28 | 2013-04-28 | 2013-03-28 | 2013-02-28 | 2013-01-28 | 2012-12-28 | 2012-11-28 | 2012-10-28 | 2012-09-28 | 2012-08-28 | 2012-07-28 | 2012-06-28 | 2012-05-28 | 2012-04-28 | 2012-03-28 | 2012-02-28 | 2012-01-28 | 2011-12-28 | 2011-11-28 | 2011-10-28 | 2011-09-28 | 2011-08-28 | 2011-07-28 | 2011-06-28 | 2011-05-28 | 2011-04-28 | 2011-03-28 | 2011-02-28 | 2011-01-28 | 2010-12-28 | 2010-11-28 | 2010-10-28 | 2010-09-28 | 2010-08-28 | 2010-07-28 | 2010-06-28 | 2010-05-28 | 2010-04-28 | 2010-03-28 | 2010-02-28 | 2010-01-28 | 2009-12-28 | 2009-11-28 | 2009-10-28 | 2009-09-28 | 2009-08-28 | 2009-07-28 | 2009-06-28 | 2009-05-28 | 2009-04-28 | 2009-03-28 | 2009-02-28 | 2009-01-28 | 2008-12-28 | 2008-11-28 | 2008-10-28 | 2008-09-28 | 2008-08-28 | 2008-07-28 | 2008-06-28 | 2008-05-28 | 2008-04-28 | 2008-03-28 | 2008-02-28 | 2008-01-28 | 2007-12-28 | 2007-11-28 | 2007-10-28 | 2007-09-28 | 2007-08-28 | 2007-07-28 | 2007-06-28 | 2007-05-28 | 2007-04-28 | 2007-03-28 | 2007-02-28 | 2007-01-28 | 2006-12-28 | 2006-11-28 | 2006-10-28 | 2006-09-28 | 2006-08-28 | 2006-07-28 | 2006-06-28 | 2006-05-28 | 2006-04-28 | 2006-03-28 | 2006-02-28 | 2006-01-28 | 2005-12-28 | 2005-11-28 | 2005-10-28 | 2005-09-28 | 2005-08-28 | 2005-07-28 | 2005-06-28 | 2005-05-28 | 2005-04-28 | 2005-03-28 | 2005-02-28 | 2005-01-28 | 2004-12-28 | 2004-11-28 | 2004-10-28 | 2004-09-28 | 2004-08-28 | 2004-07-28 | 2004-06-28 | 2004-05-28 | 2004-04-28 | 2004-03-28 | 2004-02-28 | 2004-01-28 | 2003-12-28 | 2003-11-28 | 2003-10-28 | 2003-09-28 | 2003-08-28 | 2003-07-28 | 2003-06-28 | 2003-05-28 | 2003-04-28 | 2003-03-28 | 2003-02-28 | 2003-01-28 | 2002-12-28 | 2002-11-28 | 2002-10-28 | 2002-09-28 | 2002-08-28 | 2002-07-28 | 2002-06-28 | 2002-05-28 | 2002-04-28 | 2002-03-28 | 2002-02-28 | 2002-01-28 | 2001-12-28 | 2001-11-28 | 2001-10-28 | 2001-09-28 | 2001-08-28 | 2001-07-28 | 2001-06-28 | 2001-05-28 | 2001-04-28 | 2001-03-28 | 2001-02-28 | 2001-01-28 | 2000-12-28 | 2000-11-28 | 2000-10-28 | 2000-09-28 | 2000-08-28 | 2000-07-28 | 2000-06-28 | 2000-05-28 | 2000-04-28 | 2000-03-28 | 2000-02-28 | 2000-01-28 | 1999-12-28

Key: Value:

Key: Value:

MESSAGE
DATE 2020-12-26
FROM Matthias Peng
SUBJECT Re: [Hangout - NYLXS] Confused about two development utils [EXT]
From hangout-bounces-at-nylxs.com Fri Jan 1 10:57:25 2021
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id 643B9164036;
Fri, 1 Jan 2021 10:57:24 -0500 (EST)
X-Original-To: hangout-at-www2.mrbrklyn.com
Delivered-To: hangout-at-www2.mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 1000)
id 43237164030; Fri, 1 Jan 2021 10:56:33 -0500 (EST)
Resent-From: Ruben Safir
Resent-Date: Fri, 1 Jan 2021 10:56:32 -0500
Resent-Message-ID: <20210101155632.GK15013-at-www2.mrbrklyn.com>
Resent-To: hangout-at-mrbrklyn.com
X-Original-To: ruben-at-mrbrklyn.com
Delivered-To: ruben-at-mrbrklyn.com
Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org
[3.227.148.255]) by mrbrklyn.com (Postfix) with ESMTP id 35291164017
for ; Sat, 26 Dec 2020 03:01:30 -0500 (EST)
Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153])
by mxout1-ec2-va.apache.org (ASF Mail Server at
mxout1-ec2-va.apache.org) with SMTP id B0AEF44D96
for ; Sat, 26 Dec 2020 08:01:30 +0000 (UTC)
Received: (qmail 8131 invoked by uid 500); 26 Dec 2020 08:01:30 -0000
Mailing-List: contact modperl-help-at-perl.apache.org; run by ezmlm
Precedence: bulk
Delivered-To: mailing list modperl-at-perl.apache.org
Received: (qmail 8120 invoked by uid 99); 26 Dec 2020 08:01:29 -0000
Received: from spamproc1-he-de.apache.org (HELO spamproc1-he-de.apache.org)
(116.203.196.100)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Dec 2020 08:01:29 +0000
Received: from localhost (localhost [127.0.0.1])
by spamproc1-he-de.apache.org (ASF Mail Server at spamproc1-he-de.apache.org)
with ESMTP id 26C8C1FF3A1
for ; Sat, 26 Dec 2020 08:01:29 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_MSPIKE_H2=-0.001,
SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled
Authentication-Results: spamproc1-he-de.apache.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from mx1-ec2-va.apache.org ([116.203.227.195])
by localhost (spamproc1-he-de.apache.org [116.203.196.100]) (amavisd-new,
port 10024) with ESMTP id RgafuvRUOczX for ;
Sat, 26 Dec 2020 08:01:26 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.167.196;
helo=mail-oi1-f196.google.com; envelope-from=pengmatthias-at-gmail.com;
receiver=
Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com
[209.85.167.196])
by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with
ESMTPS id B7890BC95A
for ; Sat, 26 Dec 2020 08:01:25 +0000 (UTC)
Received: by mail-oi1-f196.google.com with SMTP id x13so6566202oic.5
for ; Sat, 26 Dec 2020 00:01:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=U7SWrUJuzeU4r3T5btalDT4HmdiMxH5+7/ASjn33wgk=;
b=XoPwBRYaQQRSxtVh922IhdrD4WlfOXjYczpX9XwBn9aLpriZFpNnIi/mI9ggd1/fT0
3Yr/yknHV6g3XLBv48a9kT5fOnMgqLhOYKC8w7Mz8n2fI717zQfmu4LhxURGdl2GT8WL
g2iXKqPGe+Ey5Hl+blCag4g26JNVqBr76XR8zo6GF8QMjAyY6+rIVwv/xdmjpli5jRq+
MMfyvZUMPHOqRG+ALGeldLBOzPaxlZoJ4wvE0YipKYyM99acyEx7eDePo2rM56Ru/jgc
DRvea4xXhkoMTm5nni3oYYSnH3ZwNMnJspOEgHxcLmnqBGQ0gwjP9zwLrcHzg0VqUB+E
2Jfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=U7SWrUJuzeU4r3T5btalDT4HmdiMxH5+7/ASjn33wgk=;
b=ntJTH6QfQR+ZvFQDZLVCBNSx9iu2PRYebpt42F/1ikgeHE0iV+fPjIF9fA/9/J2+10
gq1q+JrxVAwDeJwXjXL1EmV27MXsgkNSicsX/sTJ3N0NJkngcvad7MCnLj8n3/w3ctWV
zzvYr9XDJ37NW5vKk4kKGBQY9DMvyeViip2B5j61G/NdVpF9gZMv2lel/w3yo8EEcelB
x2f7JhwKZprJ2hp4GrMFYdtwIc9gdZKWB3PbcxVobFmMJm8ZqSK7NdKmV+IpQpOC5cD1
OAXw7M1l7zWHyRftpcoFKbYeUhi8RNivNxRVe71h1t/yiR5wpV0U1EqUBDq3FucnDsKh
lzzQ==
X-Gm-Message-State: AOAM5335lloQyweVIjvmVSJ8zFS1w/g1lhj00aG3YzDG9heCqFFWuLGk
tjaiGxwaN7KW7AZryZ8ygnQBoivTDm524RjAyFY=
X-Google-Smtp-Source: ABdhPJzKulpclxTkJnuZ1mL7bC2vvIHx69zRe+i255UKqlQn5O5lfXHcx+2Uhfhlo7NuWX1PNrieo26iSJg8v16upTE=
X-Received: by 2002:a54:4815:: with SMTP id j21mr7227541oij.154.1608969685206;
Sat, 26 Dec 2020 00:01:25 -0800 (PST)
MIME-Version: 1.0
References:
<971cc41d-b30e-7fc1-25a2-4a63f028321d-at-ice-sa.com>

<90ae0836-d487-926c-89e4-696a46fae57d-at-ice-sa.com>
<335e0e3cca2e4dd3aeb5f91d83ea08c0-at-sanger.ac.uk>


<11d9dcd77b2a4de7a98592c31664eb0c-at-sanger.ac.uk>

<5638d10591eb43c58c225deff698f14c-at-sanger.ac.uk>
<477c1bbb-4647-81fe-595b-d54d0d9e00f4-at-ice-sa.com>

In-Reply-To:
From: Matthias Peng
Date: Sat, 26 Dec 2020 16:01:14 +0800
Message-ID:
To: Sandhya
Cc: modperl-at-perl.apache.org
Subject: Re: [Hangout - NYLXS] Confused about two development utils [EXT]
X-BeenThere: hangout-at-nylxs.com
X-Mailman-Version: 2.1.30rc1
List-Id: NYLXS Tech Talk and Politics
List-Unsubscribe: ,

List-Archive:
List-Post:
List-Help:
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1571511426=="
Errors-To: hangout-bounces-at-nylxs.com
Sender: "Hangout"

--===============1571511426==
Content-Type: multipart/alternative; boundary="0000000000008a8b4d05b75972a1"

--0000000000008a8b4d05b75972a1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If I have been using modperl for development, does it influence I drive
Maserati? :)


> unsubscribe.
>
> On Fri, Dec 25, 2020 at 10:30 PM Andr=C3=A9 Warnier (tomcat/perl) <
> aw-at-ice-sa.com> wrote:
>
>> Hello James.
>> Bravo and many thanks for this excellent overview of your activities. Of
>> course the setup
>> (in your previous message) and the activities are very impressive by
>> themselves.
>> But in addition, even though your message is not in itself a perl
>> advocacy message, I feel
>> that it would have its right place in some perl/mod_perl advocacy forum,
>> because it
>> touches on some general idea which are valid /also/ for perl and mod_per=
l.
>> It was very refreshing to read for once a clear expos=C3=A9 of why it is=
still
>> important
>> nowadays to think before programming, to program efficiently, and to
>> choose the right tool
>> for the job at hand (be it perl, mod_perl, or any other) without the kin=
d
>> of off-the-cuff
>> general a-priori which tend to plague these discussions.
>>
>> And even though our own (commercial) activities and setups do not have
>> anything even close
>> to the scope which you describe, I would like to say that the same basic
>> principles which
>> you mention in your expos=C3=A9 are just as valid when you scale-down as=
when
>> you scale-up.
>> ("--you can=E2=80=99t just throw memory, CPUs, power at a problem =E2=80=
=93 you have to
>> think =E2=80=93 how can I do what I need to do with the least resources.=
.")
>> Even when you think of a single server, or a single server rack, at any
>> one period in time
>> there is always a practical limit as to how much memory or CPUs you can
>> fit in a given
>> server, or how many servers you can fit in a rack, or how many additiona=
l
>> Gb of bandwidth
>> you can allocate per server, beyond which there is a sudden "quantum
>> jump" as to how
>> practical and cost-effective a whole project becomes.
>> In that sense, I particulary enjoyed your examples of the database and o=
f
>> the additional
>> power line.
>>
>>
>> On 24.12.2020 02:38, James Smith wrote:
>> > We don=E2=80=99t use perl for everything, yes we use it for web data, =
yes we
>> still use it as the
>> > glue language in a lot of cases, the most complex stuff is done with C
>> (not even C++ as
>> > that is too slow). Others on site use Python, Java, Rust, Go, PHP,
>> along with looking at
>> > using GPUs in cases where code can be highly parallelised
>> >
>> > It is not just one application =E2=80=93 but many, many applications=
=E2=80=A6 All with
>> a common goal of
>> > understanding the human genome, and using it to assist in developing
>> new understanding and
>> > techniques which can advance health care.
>> >
>> > We are a very large sequencing centre (one of the largest in the world=
)
>> =E2=80=93 what I was
>> > pointing out is that you can=E2=80=99t just throw memory, CPUs, power =
at a
>> problem =E2=80=93 you have to
>> > think =E2=80=93 how can I do what I need to do with the least resource=
s. Rather
>> than what
>> > resources can I throw at the problem.
>> >
>> > Currently we are acting as the central repository for all COVID-19
>> sequencing in the UK,
>> > along with one of the largest =E2=80=9Cwet=E2=80=9D labs sequencing da=
ta for it =E2=80=93 and
>> that is half the
>> > sequenced samples in the whole world. The UK is sequencing more
>> COVID-19 genomes a day
>> > than most other countries have sequenced since the start of the
>> pandemic in Feb/Mar. This
>> > has lead to us discovering a new more transmissible version of the
>> virus, and it what part
>> > of the country the different strains are present =E2=80=93 no other co=
untry in
>> the world has the
>> > information, technology or infrastructure in place to achieve this.
>> >
>> > But this is just a small part of the genomic sequencing we are looking
>> at =E2=80=93 we work on:
>> > * other pathogens =E2=80=93 e.g. Plasmodium (Malaria);
>> > * cancer genomes (and how effective drugs are);
>> > * are a major part of the Human Cell Atlas which is looking at how the
>> expression of genes
>> > (in the simplest terms which ones are switched on and switched off) ar=
e
>> different in
>> > different tissues;
>> > * sequencing the genomes of other animals to understand their evolutio=
n;
>> > * and looking at some other species in detail, to see what we can lear=
n
>> from them when
>> > they have defective genes;
>> >
>> > Although all these are currently scaled back so that we can work
>> relentlessly to support
>> > the medical teams and other researchers get on top of COVID-19.
>> >
>> > What is interesting is that many of the developers we have on campus
>> (well all wfh at the
>> > moment) are all (relatively) old as we learnt to develop code on
>> machines with limited CPU
>> > and limited memory =E2=80=93 so that things had to be efficient, had t=
o be
>> compact=E2=80=A6. And that is
>> > as important now as it was 20 or 30 years ago =E2=80=93 the data we ha=
ndle is
>> going up faster than
>> > Moore=E2=80=99s Law! Many of us have pride in doing things as efficien=
tly as
>> possible.
>> >
>> > It took around 10 years to sequence and assemble the first human genom=
e
>> {well we are still
>> > tinkering with it and filling in the gaps} =E2=80=93 now at the instit=
ute we
>> can sequence and
>> > assemble around 400 human genomes in a day =E2=80=93 to the same quali=
ty!
>> >
>> > So most of our issues are due to the scale of the problems we face =E2=
=80=93
>> e.g. the human genome
>> > has 3 billion base-pairs (A, C, G, Ts) , so normal solutions don=E2=80=
=99t
>> scale to that (once
>> > many years ago we looked at setting up an Oracle database where there
>> was at least 1 row
>> > for every base pair =E2=80=93 recording all variants (think of them as=
spelling
>> mistakes, for
>> > example a T rather than an A, or an extra letter inserted or deleted)
>> for that base pair=E2=80=A6
>> > The schema was set up =E2=80=93 and then they realised it would take 1=
2 months
>> to load the data
>> > which we had then (which is probably less than a millionth of what we
>> have now)!
>> >
>> > Moving compute off site is a problem as the transfer of the level of
>> data we have would
>> > cause a problem =E2=80=93 you can=E2=80=99t easily move all the data t=
o the compute =E2=80=93
>> so you have to bring
>> > the compute to the data.
>> >
>> > The site I worked on before I became a more general developer was doin=
g
>> that =E2=80=93 and the
>> > code that was written 12-15 years ago is actually still going strong =
=E2=80=93
>> it has seen a few
>> > changes over the year =E2=80=93 many displays have had to be redevelop=
ed as the
>> scale of the data
>> > has got so big that even the summary pages we produced 10 years ago
>> have to be summarised
>> > because they are so large.
>> >
>> > *From:*Mithun Bhattacharya
>> > *Sent:* 24 December 2020 00:06
>> > *To:* mod_perl list
>> > *Subject:* Re: Confused about two development utils [EXT]
>> >
>> > James would you be able to share more info about your setup ?
>> >
>> > 1. What exactly is your application doing which requires so much memor=
y
>> and CPU - is it
>> > something like gene splicing (no i don't know much about it beyond
>> Jurassic Park :D )
>> >
>> > 2. Do you feel Perl was the best choice for whatever you are doing and
>> if yes then why ?
>> > How much of your stuff is using mod_perl considering you mentioned not
>> much is web related ?
>> >
>> > 3. What are the challenges you are currently facing with your
>> implementation ?
>> >
>> > On Wed, Dec 23, 2020 at 6:58 AM James Smith >> js5-at-sanger.ac.uk>>
>> > wrote:
>> >
>> > Oh but memory is a problem =E2=80=93 but not if you have just a sm=
all
>> cluster of machines!
>> >
>> > Our boxes are larger than that =E2=80=93 but they all run virtual =
machine
>> {only a small
>> > proportion web related} =E2=80=93 machines/memory would rapidly be=
come in
>> our data centre - we
>> > run VMWARE [995 hosts] and openstack [10,000s of hosts] + a
>> selection of large memory
>> > machines {measured in TBs of memory per machine }.
>> >
>> > We would be looking at somewhere between 0.5 PB and 1 PB of memory
>> =E2=80=93 not just the
>> > price of buying that amount of memory - for many machines we need
>> the fastest memory
>> > money can buy for the workload, but we would need a lot more CPUs
>> then we currently
>> > have as we would need a larger amount of machines to have 64GB
>> virtual machines {we
>> > would get 2 VMs per host. We currently have approx. 1-2000 CPUs
>> running our hardware
>> > (last time I had a figure) =E2=80=93 it would probably need to go =
to
>> approximately 5-10,000!
>> > It is not just the initial outlay but the environmental and
>> financial cost of running
>> > that number of machines, and finding space to run them without
>> putting the cooling
>> > costs through the roof!! That is without considering what
>> additional constraints on
>> > storage having the extra machines may have (at the last count a
>> year ago we had over
>> > 30 PBytes of storage on side =E2=80=93 and a large amount of offsi=
te backup.
>> >
>> > We would also stretch the amount of power we can get from the
>> national grid to power
>> > it all - we currently have 3 feeds from different part of the
>> national grid (we are
>> > fortunately in position where this is possible) and the dedicated
>> link we would need
>> > to add more power would be at least 50 miles long!
>> >
>> > So - managing cores/memory is vitally important to us =E2=80=93 mo=
ving to
>> the cloud is an
>> > option we are looking at =E2=80=93 but that is more than 4 times t=
he price
>> of our onsite
>> > set-up (with substantial discounts from AWS) and would require an
>> upgrade of our
>> > existing link to the internet =E2=80=93 which is currently 40Gbit =
of data
>> (I think).
>> >
>> > Currently we are analysing a very large amounts of data directly
>> linked to the current
>> > major world problem =E2=80=93 this is why the UK is currently bein=
g
>> isolated as we have
>> > discovered and can track a new strain, in near real time =E2=80=93=
other
>> countries have no
>> > ability to do this =E2=80=93 we in a day can and do handle, sequen=
ce and
>> analyse more samples
>> > than the whole of France has sequenced since February. We probably
>> don=E2=80=99t have more of
>> > the new variant strain than in other areas of the world =E2=80=93 =
it is
>> just that we know we
>> > have because of the amount of sequencing and analysis that we in
>> the UK have done.
>> >
>> > *From:*Matthias Peng >> pengmatthias-at-gmail.com>>
>> > *Sent:* 23 December 2020 12:02
>> > *To:* mod_perl list >> modperl-at-perl.apache.org>>
>> > *Subject:* Re: Confused about two development utils [EXT]
>> >
>> > Today memory is not serious problem, each of our server has 64GB
>> memory.
>> >
>> >
>> > Forgot to add - so our FCGI servers need a lot (and I mean a
>> lot) more memory than
>> > the mod_perl servers to serve the same level of content (just
>> in case memory blows
>> > up with FCGI backends)
>> >
>> > -----Original Message-----
>> > From: James Smith >
>> > Sent: 23 December 2020 11:34
>> > To: Andr=C3=A9 Warnier (tomcat/perl) >> aw-at-ice-sa.com>>;
>> > modperl-at-perl.apache.org
>> > Subject: RE: Confused about two development utils [EXT]
>> >
>> >
>> > > This costs memory, and all the more since many perl modules
>> are not
>> > thread-safe, so if you use them in your code, at this moment
>> the only safe way to
>> > do it is to use the Apache httpd prefork model. This means tha=
t
>> each Apache httpd
>> > child process has its own copy of the perl interpreter, which
>> means that the
>> > memory used by this embedded perl interpreter has to be counte=
d
>> n times (as many
>> > times as there are Apache httpd child processes running at any
>> one time).
>> >
>> > This isn=E2=80=99t quite true - if you load modules before the=
process
>> forks then they can
>> > cleverly share the same parts of memory. It is useful to be
>> able to "pre-load"
>> > core functionality which is used across all functions {this is
>> the case in Linux
>> > anyway}. It also speeds up child process generation as the
>> modules are already in
>> > memory and converted to byte code.
>> >
>> > One of the great advantages of mod_perl is Apache2::SizeLimit
>> which can blow away
>> > large child process - and then if needed create new ones. This
>> is not the case
>> > with some of the FCGI solutions as the individual processes ca=
n
>> grow if there is a
>> > memory leak or a request that retrieves a large amount of
>> content (even if not
>> > served), but perl can't give the memory back. So FCGI processe=
s
>> only get bigger
>> > and bigger and eventually blow up memory (or hit swap first)
>> >
>> >
>> >
>> >
>> >
>> > --
>> > The Wellcome Sanger Institute is operated by Genome Research
>> Limited, a charity
>> > registered in England with number 1021457 and a company
>> registered in England
>> > with number 2742969, whose registered office is 215 Euston
>> Road, London, NW1
>> =3Dgmail&source=3Dg>
>> 2
>> > [google.com]
>> > <
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_ma=
ps_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-=
26source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=
=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=
=3DxU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&e=3D
>> >BE.
>> >
>> >
>> >
>> > --
>> > The Wellcome Sanger Institute is operated by Genome Research
>> > Limited, a charity registered in England with number 1021457
>> and a
>> > company registered in England with number 2742969, whose
>> registered
>> > office is 215 Euston Road, London, NW1
>> =3Dgmail&source=3Dg>
>> 2 [google.com]
>> > <
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_ma=
ps_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-=
26source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=
=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=
=3DxU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&e=3D
>> >BE.
>> >
>> > -- The Wellcome Sanger Institute is operated by Genome Research
>> Limited, a charity
>> > registered in England with number 1021457 and a company registered
>> in England with
>> > number 2742969, whose registered office is 215 Euston Road,
>> London, NW1 2BE
>> ry=3Dgmail&source=3Dg>
>> .
>> >
>> > -- The Wellcome Sanger Institute is operated by Genome Research
>> Limited, a charity
>> > registered in England with number 1021457 and a company registered in
>> England with number
>> > 2742969, whose registered office is 215 Euston Road, London, NW1 2BE
>> ry=3Dgmail&source=3Dg>
>> .
>>
>>

--0000000000008a8b4d05b75972a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If I have been using modperl for development, does it inf=
luence I drive Maserati? :)

quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">

unsubscribe.

ass=3D"gmail_quote">
On Fri, Dec 25, 2=
020 at 10:30 PM Andr=C3=A9 Warnier (tomcat/perl) <ce-sa.com" target=3D"_blank">aw-at-ice-sa.com> wrote:
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex">Hello James.

Bravo and many thanks for this excellent overview of your activities. Of co=
urse the setup

(in your previous message) and the activities are very impressive by themse=
lves.

But in addition, even though your message is not in itself a perl advocacy =
message, I feel

that it would have its right place in some perl/mod_perl advocacy forum, be=
cause it

touches on some general idea which are valid /also/ for perl and mod_perl.<=
br>
It was very refreshing to read for once a clear expos=C3=A9 of why it is st=
ill important

nowadays to think before programming, to program efficiently, and to choose=
the right tool

for the job at hand (be it perl, mod_perl, or any other) without the kind o=
f off-the-cuff

general a-priori which tend to plague these discussions.



And even though our own (commercial) activities and setups do not have anyt=
hing even close

to the scope which you describe, I would like to say that the same basic pr=
inciples which

you mention in your expos=C3=A9 are just as valid when you scale-down as wh=
en you scale-up.

("--you can=E2=80=99t just throw memory, CPUs, power at a problem =E2=
=80=93 you have to

think =E2=80=93 how can I do what I need to do with the least resources..&q=
uot;)

Even when you think of a single server, or a single server rack, at any one=
period in time

there is always a practical limit as to how much memory or CPUs you can fit=
in a given

server, or how many servers you can fit in a rack, or how many additional G=
b of bandwidth

you can allocate per server, beyond which there is a sudden "quantum j=
ump" as to how

practical and cost-effective a whole project becomes.

In that sense, I particulary enjoyed your examples of the database and of t=
he additional

power line.





On 24.12.2020 02:38, James Smith wrote:

> We don=E2=80=99t use perl for everything, yes we use it for web data, =
yes we still use it as the

> glue language in a lot of cases, the most complex stuff is done with C=
(not even C++ as

> that is too slow). Others on site use Python, Java, Rust, Go, PHP, alo=
ng with looking at

> using GPUs in cases where code can be highly parallelised

>

> It is not just one application =E2=80=93 but many, many applications=
=E2=80=A6 All with a common goal of

> understanding the human genome, and using it to assist in developing n=
ew understanding and

> techniques which can advance health care.

>

> We are a very large sequencing centre (one of the largest in the world=
) =E2=80=93 what I was

> pointing out is that you can=E2=80=99t just throw memory, CPUs, power =
at a problem =E2=80=93 you have to

> think =E2=80=93 how can I do what I need to do with the least resource=
s. Rather than what

> resources can I throw at the problem.

>

> Currently we are acting as the central repository for all COVID-19 seq=
uencing in the UK,

> along with one of the largest =E2=80=9Cwet=E2=80=9D labs sequencing da=
ta for it =E2=80=93 and that is half the

> sequenced samples in the whole world. The UK is sequencing more COVID-=
19 genomes a day

> than most other countries have sequenced since the start of the pandem=
ic in Feb/Mar. This

> has lead to us discovering a new more transmissible version of the vir=
us, and it what part

> of the country the different strains are present =E2=80=93 no other co=
untry in the world has the

> information, technology or infrastructure in place to achieve this.>
>

> But this is just a small part of the genomic sequencing we are looking=
at =E2=80=93 we work on:

> * other pathogens =E2=80=93 e.g. Plasmodium (Malaria);

> * cancer genomes (and how effective drugs are);

> * are a major part of the Human Cell Atlas which is looking at how the=
expression of genes

> (in the simplest terms which ones are switched on and switched off) ar=
e different in

> different tissues;

> * sequencing the genomes of other animals to understand their evolutio=
n;

> * and looking at some other species in detail, to see what we can lear=
n from them when

> they have defective genes;

>

> Although all these are currently scaled back so that we can work relen=
tlessly to support

> the medical teams and other researchers get on top of COVID-19.

>

> What is interesting is that many of the developers we have on campus (=
well all wfh at the

> moment) are all (relatively) old as we learnt to develop code on machi=
nes with limited CPU

> and limited memory =E2=80=93 so that things had to be efficient, had t=
o be compact=E2=80=A6. And that is

> as important now as it was 20 or 30 years ago =E2=80=93 the data we ha=
ndle is going up faster than

> Moore=E2=80=99s Law! Many of us have pride in doing things as efficien=
tly as possible.

>

> It took around 10 years to sequence and assemble the first human genom=
e {well we are still

> tinkering with it and filling in the gaps} =E2=80=93 now at the instit=
ute we can sequence and

> assemble around 400 human genomes in a day =E2=80=93 to the same quali=
ty!

>

> So most of our issues are due to the scale of the problems we face =E2=
=80=93 e.g. the human genome

> has 3 billion base-pairs (A, C, G, Ts) , so normal solutions don=E2=80=
=99t scale to that (once

> many years ago we looked at setting up an Oracle database where there =
was at least 1 row

> for every base pair =E2=80=93 recording all variants (think of them as=
spelling mistakes, for

> example a T rather than an A, or an extra letter inserted or deleted) =
for that base pair=E2=80=A6

> The schema was set up =E2=80=93 and then they realised it would take 1=
2 months to load the data

> which we had then (which is probably less than a millionth of what we =
have now)!

>

> Moving compute off site is a problem as the transfer of the level of d=
ata we have would

> cause a problem =E2=80=93 you can=E2=80=99t easily move all the data t=
o the compute =E2=80=93 so you have to bring

> the compute to the data.

>

> The site I worked on before I became a more general developer was doin=
g that =E2=80=93 and the

> code that was written 12-15 years ago is actually still going strong =
=E2=80=93 it has seen a few

> changes over the year =E2=80=93 many displays have had to be redevelop=
ed as the scale of the data

> has got so big that even the summary pages we produced 10 years ago ha=
ve to be summarised

> because they are so large.

>

> *From:*Mithun Bhattacharya <get=3D"_blank">mithnb-at-gmail.com>

> *Sent:* 24 December 2020 00:06

> *To:* mod_perl list <get=3D"_blank">modperl-at-perl.apache.org>

> *Subject:* Re: Confused about two development utils [EXT]

>

> James would you be able to share more info about your setup ?

>

> 1. What exactly is your application doing which requires so much memor=
y and CPU - is it

> something like gene splicing (no i don't know much about it beyond=
Jurassic Park :D )

>

> 2. Do you feel Perl was the best choice for whatever you are doing and=
if yes then why ?

> How much of your stuff is using mod_perl considering you mentioned not=
much is web related ?

>

> 3. What are the challenges you are currently facing with your implemen=
tation ?

>

> On Wed, Dec 23, 2020 at 6:58 AM James Smith <sanger.ac.uk" target=3D"_blank">js5-at-sanger.ac.uk <mailto:mailto:js5-at-sanger.ac.uk" target=3D"_blank">js5-at-sanger.ac.uk>> >
> wrote:

>

>=C2=A0 =C2=A0 =C2=A0Oh but memory is a problem =E2=80=93 but not if you=
have just a small cluster of machines!

>

>=C2=A0 =C2=A0 =C2=A0Our boxes are larger than that =E2=80=93 but they a=
ll run virtual machine {only a small

>=C2=A0 =C2=A0 =C2=A0proportion web related} =E2=80=93 machines/memory w=
ould rapidly become in our data centre - we

>=C2=A0 =C2=A0 =C2=A0run VMWARE [995 hosts] and openstack [10,000s of ho=
sts] + a selection of large memory

>=C2=A0 =C2=A0 =C2=A0machines {measured in TBs of memory per machine }.<=
br>
>

>=C2=A0 =C2=A0 =C2=A0We would be looking at somewhere between 0.5 PB and=
1 PB of memory =E2=80=93 not just the

>=C2=A0 =C2=A0 =C2=A0price of buying that amount of memory - for many ma=
chines we need the fastest memory

>=C2=A0 =C2=A0 =C2=A0money can buy for the workload, but we would need a=
lot more CPUs then we currently

>=C2=A0 =C2=A0 =C2=A0have as we would need a larger amount of machines t=
o have 64GB virtual machines {we

>=C2=A0 =C2=A0 =C2=A0would get 2 VMs per host. We currently have approx.=
1-2000 CPUs running our hardware

>=C2=A0 =C2=A0 =C2=A0(last time I had a figure) =E2=80=93 it would proba=
bly need to go to approximately 5-10,000!

>=C2=A0 =C2=A0 =C2=A0It is not just the initial outlay but the environme=
ntal and financial cost of running

>=C2=A0 =C2=A0 =C2=A0that number of machines, and finding space to run t=
hem without putting the cooling

>=C2=A0 =C2=A0 =C2=A0costs through the roof!! That is without considerin=
g what additional constraints on

>=C2=A0 =C2=A0 =C2=A0storage having the extra machines may have (at the =
last count a year ago we had over

>=C2=A0 =C2=A0 =C2=A030 PBytes of storage on side =E2=80=93 and a large =
amount of offsite backup.

>

>=C2=A0 =C2=A0 =C2=A0We would also stretch the amount of power we can ge=
t from the national grid to power

>=C2=A0 =C2=A0 =C2=A0it all - we currently have 3 feeds from different p=
art of the national grid (we are

>=C2=A0 =C2=A0 =C2=A0fortunately in position where this is possible) and=
the dedicated link we would need

>=C2=A0 =C2=A0 =C2=A0to add more power would be at least 50 miles long!<=
br>
>

>=C2=A0 =C2=A0 =C2=A0So - managing cores/memory is vitally important to =
us =E2=80=93 moving to the cloud is an

>=C2=A0 =C2=A0 =C2=A0option we are looking at =E2=80=93 but that is more=
than 4 times the price of our onsite

>=C2=A0 =C2=A0 =C2=A0set-up (with substantial discounts from AWS) and wo=
uld require an upgrade of our

>=C2=A0 =C2=A0 =C2=A0existing link to the internet =E2=80=93 which is cu=
rrently 40Gbit of data (I think).

>

>=C2=A0 =C2=A0 =C2=A0Currently we are analysing a very large amounts of =
data directly linked to the current

>=C2=A0 =C2=A0 =C2=A0major world problem =E2=80=93 this is why the UK is=
currently being isolated as we have

>=C2=A0 =C2=A0 =C2=A0discovered and can track a new strain, in near real=
time =E2=80=93 other countries have no

>=C2=A0 =C2=A0 =C2=A0ability to do this =E2=80=93 we in a day can and do=
handle, sequence and analyse more samples

>=C2=A0 =C2=A0 =C2=A0than the whole of France has sequenced since Februa=
ry. We probably don=E2=80=99t have more of

>=C2=A0 =C2=A0 =C2=A0the new variant strain than in other areas of the w=
orld =E2=80=93 it is just that we know we

>=C2=A0 =C2=A0 =C2=A0have because of the amount of sequencing and analys=
is that we in the UK have done.

>

>=C2=A0 =C2=A0 =C2=A0*From:*Matthias Peng <hias-at-gmail.com" target=3D"_blank">pengmatthias-at-gmail.com <mailto:href=3D"mailto:pengmatthias-at-gmail.com" target=3D"_blank">pengmatthias-at-gmail=
.com
>>

>=C2=A0 =C2=A0 =C2=A0*Sent:* 23 December 2020 12:02

>=C2=A0 =C2=A0 =C2=A0*To:* mod_perl list <erl.apache.org" target=3D"_blank">modperl-at-perl.apache.org <mailto: href=3D"mailto:modperl-at-perl.apache.org" target=3D"_blank">modperl-at-perl.apa=
che.org>>

>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: Confused about two development utils=
[EXT]

>

>=C2=A0 =C2=A0 =C2=A0Today memory is not serious problem, each of our se=
rver has 64GB memory.

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forgot to add - so our FCGI servers n=
eed a lot (and I mean a lot) more memory than

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the mod_perl servers to serve the sam=
e level of content (just in case memory blows

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0up with FCGI backends)

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----Original Message-----

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: James Smith <to:js5-at-sanger.ac.uk" target=3D"_blank">js5-at-sanger.ac.uk <mailto:ref=3D"mailto:js5-at-sanger.ac.uk" target=3D"_blank">js5-at-sanger.ac.uk>&=
gt;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: 23 December 2020 11:34

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Andr=C3=A9 Warnier (tomcat/perl) =
<aw-at-ice-sa.com &l=
t;mailto:aw-at-ice-sa.coma>>>;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
.org" target=3D"_blank">modperl-at-perl.apache.org <mailto:ailto:modperl-at-perl.apache.org" target=3D"_blank">modperl-at-perl.apache.org
>>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: RE: Confused about two devel=
opment utils [EXT]

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > This costs memory, and all the =
more since many perl modules are not

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thread-safe, so if you use them in yo=
ur code, at this moment the only safe way to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0do it is to use the Apache httpd pref=
ork model. This means that each Apache httpd

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0child process has its own copy of the=
perl interpreter, which means that the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memory used by this embedded perl int=
erpreter has to be counted n times (as many

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0times as there are Apache httpd child=
processes running at any one time).

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This isn=E2=80=99t quite true - if yo=
u load modules before the process forks then they can

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cleverly share the same parts of memo=
ry. It is useful to be able to "pre-load"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0core functionality which is used acro=
ss all functions {this is the case in Linux

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyway}. It also speeds up child proc=
ess generation as the modules are already in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memory and converted to byte code.>
>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One of the great advantages of mod_pe=
rl is Apache2::SizeLimit which can blow away

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0large child process - and then if nee=
ded create new ones. This is not the case

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with some of the FCGI solutions as th=
e individual processes can grow if there is a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memory leak or a request that retriev=
es a large amount of content (even if not

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0served), but perl can't give the =
memory back. So FCGI processes only get bigger

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and bigger and eventually blow up mem=
ory (or hit swap first)

>

>

>

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Wellcome Sanger Institute =
is operated by Genome Research=C2=A0 Limited, a charity

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registered in England with number 102=
1457 and a=C2=A0 company registered in England

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with number 2742969, whose registered=
=C2=A0 office is
oad,+London,+NW1?entry=3Dgmail&source=3Dg">215 Euston Road, London, NW1=
2

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0["noreferrer" target=3D"_blank">google.com]

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_maps_search_s-2B215-2BEusto=
n-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-26source-3Dg&d=3DDwMF=
aQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3DoH2yp0ge1ecj=
4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=3DxU3F=
4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&e=3D" rel=3D"noreferrer" target=
=3D"_blank">https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.goog=
le.com_maps_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry=
-3Dgmail-26source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8u=
clZFI0SqQnqBo&r=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_o=
gNXEVR-4ixdkrhy5khQjA&s=3DxU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&a=
mp;e=3D
>BE.

>

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Wellcome Sanger Institute =
is operated by Genome Research

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Limited, a charity registered =
in England with number 1021457 and a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0company registered in England =
with number 2742969, whose registered

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0office is ww.google.com/maps/search/215+Euston+Road,+London,+NW1?entry=3Dgmail&so=
urce=3Dg">215 Euston Road, London, NW1
2 [ rel=3D"noreferrer" target=3D"_blank">google.com]

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_maps_search_s-2B215-2BEusto=
n-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-26source-3Dg&d=3DDwMF=
aQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3DoH2yp0ge1ecj=
4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=3DxU3F=
4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&e=3D" rel=3D"noreferrer" target=
=3D"_blank">https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.goog=
le.com_maps_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry=
-3Dgmail-26source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8u=
clZFI0SqQnqBo&r=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_o=
gNXEVR-4ixdkrhy5khQjA&s=3DxU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&a=
mp;e=3D
>BE.

>

>=C2=A0 =C2=A0 =C2=A0-- The Wellcome Sanger Institute is operated by Gen=
ome Research Limited, a charity

>=C2=A0 =C2=A0 =C2=A0registered in England with number 1021457 and a com=
pany registered in England with

>=C2=A0 =C2=A0 =C2=A0number 2742969, whose registered office is =3D"https://www.google.com/maps/search/215+Euston+Road,+London,+NW1+2BE?ent=
ry=3Dgmail&source=3Dg">215 Euston Road, London, NW1 2BE
.

>

> -- The Wellcome Sanger Institute is operated by Genome Research Limite=
d, a charity

> registered in England with number 1021457 and a company registered in =
England with number

> 2742969, whose registered office is maps/search/215+Euston+Road,+London,+NW1+2BE?entry=3Dgmail&source=3Dg">=
215 Euston Road, London, NW1 2BE
.






--0000000000008a8b4d05b75972a1--

--===============1571511426==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout

--===============1571511426==--

--===============1571511426==
Content-Type: multipart/alternative; boundary="0000000000008a8b4d05b75972a1"

--0000000000008a8b4d05b75972a1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If I have been using modperl for development, does it influence I drive
Maserati? :)


> unsubscribe.
>
> On Fri, Dec 25, 2020 at 10:30 PM Andr=C3=A9 Warnier (tomcat/perl) <
> aw-at-ice-sa.com> wrote:
>
>> Hello James.
>> Bravo and many thanks for this excellent overview of your activities. Of
>> course the setup
>> (in your previous message) and the activities are very impressive by
>> themselves.
>> But in addition, even though your message is not in itself a perl
>> advocacy message, I feel
>> that it would have its right place in some perl/mod_perl advocacy forum,
>> because it
>> touches on some general idea which are valid /also/ for perl and mod_per=
l.
>> It was very refreshing to read for once a clear expos=C3=A9 of why it is=
still
>> important
>> nowadays to think before programming, to program efficiently, and to
>> choose the right tool
>> for the job at hand (be it perl, mod_perl, or any other) without the kin=
d
>> of off-the-cuff
>> general a-priori which tend to plague these discussions.
>>
>> And even though our own (commercial) activities and setups do not have
>> anything even close
>> to the scope which you describe, I would like to say that the same basic
>> principles which
>> you mention in your expos=C3=A9 are just as valid when you scale-down as=
when
>> you scale-up.
>> ("--you can=E2=80=99t just throw memory, CPUs, power at a problem =E2=80=
=93 you have to
>> think =E2=80=93 how can I do what I need to do with the least resources.=
.")
>> Even when you think of a single server, or a single server rack, at any
>> one period in time
>> there is always a practical limit as to how much memory or CPUs you can
>> fit in a given
>> server, or how many servers you can fit in a rack, or how many additiona=
l
>> Gb of bandwidth
>> you can allocate per server, beyond which there is a sudden "quantum
>> jump" as to how
>> practical and cost-effective a whole project becomes.
>> In that sense, I particulary enjoyed your examples of the database and o=
f
>> the additional
>> power line.
>>
>>
>> On 24.12.2020 02:38, James Smith wrote:
>> > We don=E2=80=99t use perl for everything, yes we use it for web data, =
yes we
>> still use it as the
>> > glue language in a lot of cases, the most complex stuff is done with C
>> (not even C++ as
>> > that is too slow). Others on site use Python, Java, Rust, Go, PHP,
>> along with looking at
>> > using GPUs in cases where code can be highly parallelised
>> >
>> > It is not just one application =E2=80=93 but many, many applications=
=E2=80=A6 All with
>> a common goal of
>> > understanding the human genome, and using it to assist in developing
>> new understanding and
>> > techniques which can advance health care.
>> >
>> > We are a very large sequencing centre (one of the largest in the world=
)
>> =E2=80=93 what I was
>> > pointing out is that you can=E2=80=99t just throw memory, CPUs, power =
at a
>> problem =E2=80=93 you have to
>> > think =E2=80=93 how can I do what I need to do with the least resource=
s. Rather
>> than what
>> > resources can I throw at the problem.
>> >
>> > Currently we are acting as the central repository for all COVID-19
>> sequencing in the UK,
>> > along with one of the largest =E2=80=9Cwet=E2=80=9D labs sequencing da=
ta for it =E2=80=93 and
>> that is half the
>> > sequenced samples in the whole world. The UK is sequencing more
>> COVID-19 genomes a day
>> > than most other countries have sequenced since the start of the
>> pandemic in Feb/Mar. This
>> > has lead to us discovering a new more transmissible version of the
>> virus, and it what part
>> > of the country the different strains are present =E2=80=93 no other co=
untry in
>> the world has the
>> > information, technology or infrastructure in place to achieve this.
>> >
>> > But this is just a small part of the genomic sequencing we are looking
>> at =E2=80=93 we work on:
>> > * other pathogens =E2=80=93 e.g. Plasmodium (Malaria);
>> > * cancer genomes (and how effective drugs are);
>> > * are a major part of the Human Cell Atlas which is looking at how the
>> expression of genes
>> > (in the simplest terms which ones are switched on and switched off) ar=
e
>> different in
>> > different tissues;
>> > * sequencing the genomes of other animals to understand their evolutio=
n;
>> > * and looking at some other species in detail, to see what we can lear=
n
>> from them when
>> > they have defective genes;
>> >
>> > Although all these are currently scaled back so that we can work
>> relentlessly to support
>> > the medical teams and other researchers get on top of COVID-19.
>> >
>> > What is interesting is that many of the developers we have on campus
>> (well all wfh at the
>> > moment) are all (relatively) old as we learnt to develop code on
>> machines with limited CPU
>> > and limited memory =E2=80=93 so that things had to be efficient, had t=
o be
>> compact=E2=80=A6. And that is
>> > as important now as it was 20 or 30 years ago =E2=80=93 the data we ha=
ndle is
>> going up faster than
>> > Moore=E2=80=99s Law! Many of us have pride in doing things as efficien=
tly as
>> possible.
>> >
>> > It took around 10 years to sequence and assemble the first human genom=
e
>> {well we are still
>> > tinkering with it and filling in the gaps} =E2=80=93 now at the instit=
ute we
>> can sequence and
>> > assemble around 400 human genomes in a day =E2=80=93 to the same quali=
ty!
>> >
>> > So most of our issues are due to the scale of the problems we face =E2=
=80=93
>> e.g. the human genome
>> > has 3 billion base-pairs (A, C, G, Ts) , so normal solutions don=E2=80=
=99t
>> scale to that (once
>> > many years ago we looked at setting up an Oracle database where there
>> was at least 1 row
>> > for every base pair =E2=80=93 recording all variants (think of them as=
spelling
>> mistakes, for
>> > example a T rather than an A, or an extra letter inserted or deleted)
>> for that base pair=E2=80=A6
>> > The schema was set up =E2=80=93 and then they realised it would take 1=
2 months
>> to load the data
>> > which we had then (which is probably less than a millionth of what we
>> have now)!
>> >
>> > Moving compute off site is a problem as the transfer of the level of
>> data we have would
>> > cause a problem =E2=80=93 you can=E2=80=99t easily move all the data t=
o the compute =E2=80=93
>> so you have to bring
>> > the compute to the data.
>> >
>> > The site I worked on before I became a more general developer was doin=
g
>> that =E2=80=93 and the
>> > code that was written 12-15 years ago is actually still going strong =
=E2=80=93
>> it has seen a few
>> > changes over the year =E2=80=93 many displays have had to be redevelop=
ed as the
>> scale of the data
>> > has got so big that even the summary pages we produced 10 years ago
>> have to be summarised
>> > because they are so large.
>> >
>> > *From:*Mithun Bhattacharya
>> > *Sent:* 24 December 2020 00:06
>> > *To:* mod_perl list
>> > *Subject:* Re: Confused about two development utils [EXT]
>> >
>> > James would you be able to share more info about your setup ?
>> >
>> > 1. What exactly is your application doing which requires so much memor=
y
>> and CPU - is it
>> > something like gene splicing (no i don't know much about it beyond
>> Jurassic Park :D )
>> >
>> > 2. Do you feel Perl was the best choice for whatever you are doing and
>> if yes then why ?
>> > How much of your stuff is using mod_perl considering you mentioned not
>> much is web related ?
>> >
>> > 3. What are the challenges you are currently facing with your
>> implementation ?
>> >
>> > On Wed, Dec 23, 2020 at 6:58 AM James Smith >> js5-at-sanger.ac.uk>>
>> > wrote:
>> >
>> > Oh but memory is a problem =E2=80=93 but not if you have just a sm=
all
>> cluster of machines!
>> >
>> > Our boxes are larger than that =E2=80=93 but they all run virtual =
machine
>> {only a small
>> > proportion web related} =E2=80=93 machines/memory would rapidly be=
come in
>> our data centre - we
>> > run VMWARE [995 hosts] and openstack [10,000s of hosts] + a
>> selection of large memory
>> > machines {measured in TBs of memory per machine }.
>> >
>> > We would be looking at somewhere between 0.5 PB and 1 PB of memory
>> =E2=80=93 not just the
>> > price of buying that amount of memory - for many machines we need
>> the fastest memory
>> > money can buy for the workload, but we would need a lot more CPUs
>> then we currently
>> > have as we would need a larger amount of machines to have 64GB
>> virtual machines {we
>> > would get 2 VMs per host. We currently have approx. 1-2000 CPUs
>> running our hardware
>> > (last time I had a figure) =E2=80=93 it would probably need to go =
to
>> approximately 5-10,000!
>> > It is not just the initial outlay but the environmental and
>> financial cost of running
>> > that number of machines, and finding space to run them without
>> putting the cooling
>> > costs through the roof!! That is without considering what
>> additional constraints on
>> > storage having the extra machines may have (at the last count a
>> year ago we had over
>> > 30 PBytes of storage on side =E2=80=93 and a large amount of offsi=
te backup.
>> >
>> > We would also stretch the amount of power we can get from the
>> national grid to power
>> > it all - we currently have 3 feeds from different part of the
>> national grid (we are
>> > fortunately in position where this is possible) and the dedicated
>> link we would need
>> > to add more power would be at least 50 miles long!
>> >
>> > So - managing cores/memory is vitally important to us =E2=80=93 mo=
ving to
>> the cloud is an
>> > option we are looking at =E2=80=93 but that is more than 4 times t=
he price
>> of our onsite
>> > set-up (with substantial discounts from AWS) and would require an
>> upgrade of our
>> > existing link to the internet =E2=80=93 which is currently 40Gbit =
of data
>> (I think).
>> >
>> > Currently we are analysing a very large amounts of data directly
>> linked to the current
>> > major world problem =E2=80=93 this is why the UK is currently bein=
g
>> isolated as we have
>> > discovered and can track a new strain, in near real time =E2=80=93=
other
>> countries have no
>> > ability to do this =E2=80=93 we in a day can and do handle, sequen=
ce and
>> analyse more samples
>> > than the whole of France has sequenced since February. We probably
>> don=E2=80=99t have more of
>> > the new variant strain than in other areas of the world =E2=80=93 =
it is
>> just that we know we
>> > have because of the amount of sequencing and analysis that we in
>> the UK have done.
>> >
>> > *From:*Matthias Peng >> pengmatthias-at-gmail.com>>
>> > *Sent:* 23 December 2020 12:02
>> > *To:* mod_perl list >> modperl-at-perl.apache.org>>
>> > *Subject:* Re: Confused about two development utils [EXT]
>> >
>> > Today memory is not serious problem, each of our server has 64GB
>> memory.
>> >
>> >
>> > Forgot to add - so our FCGI servers need a lot (and I mean a
>> lot) more memory than
>> > the mod_perl servers to serve the same level of content (just
>> in case memory blows
>> > up with FCGI backends)
>> >
>> > -----Original Message-----
>> > From: James Smith >
>> > Sent: 23 December 2020 11:34
>> > To: Andr=C3=A9 Warnier (tomcat/perl) >> aw-at-ice-sa.com>>;
>> > modperl-at-perl.apache.org
>> > Subject: RE: Confused about two development utils [EXT]
>> >
>> >
>> > > This costs memory, and all the more since many perl modules
>> are not
>> > thread-safe, so if you use them in your code, at this moment
>> the only safe way to
>> > do it is to use the Apache httpd prefork model. This means tha=
t
>> each Apache httpd
>> > child process has its own copy of the perl interpreter, which
>> means that the
>> > memory used by this embedded perl interpreter has to be counte=
d
>> n times (as many
>> > times as there are Apache httpd child processes running at any
>> one time).
>> >
>> > This isn=E2=80=99t quite true - if you load modules before the=
process
>> forks then they can
>> > cleverly share the same parts of memory. It is useful to be
>> able to "pre-load"
>> > core functionality which is used across all functions {this is
>> the case in Linux
>> > anyway}. It also speeds up child process generation as the
>> modules are already in
>> > memory and converted to byte code.
>> >
>> > One of the great advantages of mod_perl is Apache2::SizeLimit
>> which can blow away
>> > large child process - and then if needed create new ones. This
>> is not the case
>> > with some of the FCGI solutions as the individual processes ca=
n
>> grow if there is a
>> > memory leak or a request that retrieves a large amount of
>> content (even if not
>> > served), but perl can't give the memory back. So FCGI processe=
s
>> only get bigger
>> > and bigger and eventually blow up memory (or hit swap first)
>> >
>> >
>> >
>> >
>> >
>> > --
>> > The Wellcome Sanger Institute is operated by Genome Research
>> Limited, a charity
>> > registered in England with number 1021457 and a company
>> registered in England
>> > with number 2742969, whose registered office is 215 Euston
>> Road, London, NW1
>> =3Dgmail&source=3Dg>
>> 2
>> > [google.com]
>> > <
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_ma=
ps_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-=
26source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=
=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=
=3DxU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&e=3D
>> >BE.
>> >
>> >
>> >
>> > --
>> > The Wellcome Sanger Institute is operated by Genome Research
>> > Limited, a charity registered in England with number 1021457
>> and a
>> > company registered in England with number 2742969, whose
>> registered
>> > office is 215 Euston Road, London, NW1
>> =3Dgmail&source=3Dg>
>> 2 [google.com]
>> > <
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_ma=
ps_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-=
26source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=
=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=
=3DxU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&e=3D
>> >BE.
>> >
>> > -- The Wellcome Sanger Institute is operated by Genome Research
>> Limited, a charity
>> > registered in England with number 1021457 and a company registered
>> in England with
>> > number 2742969, whose registered office is 215 Euston Road,
>> London, NW1 2BE
>> ry=3Dgmail&source=3Dg>
>> .
>> >
>> > -- The Wellcome Sanger Institute is operated by Genome Research
>> Limited, a charity
>> > registered in England with number 1021457 and a company registered in
>> England with number
>> > 2742969, whose registered office is 215 Euston Road, London, NW1 2BE
>> ry=3Dgmail&source=3Dg>
>> .
>>
>>

--0000000000008a8b4d05b75972a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If I have been using modperl for development, does it inf=
luence I drive Maserati? :)

quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">

unsubscribe.

ass=3D"gmail_quote">
On Fri, Dec 25, 2=
020 at 10:30 PM Andr=C3=A9 Warnier (tomcat/perl) <ce-sa.com" target=3D"_blank">aw-at-ice-sa.com> wrote:
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex">Hello James.

Bravo and many thanks for this excellent overview of your activities. Of co=
urse the setup

(in your previous message) and the activities are very impressive by themse=
lves.

But in addition, even though your message is not in itself a perl advocacy =
message, I feel

that it would have its right place in some perl/mod_perl advocacy forum, be=
cause it

touches on some general idea which are valid /also/ for perl and mod_perl.<=
br>
It was very refreshing to read for once a clear expos=C3=A9 of why it is st=
ill important

nowadays to think before programming, to program efficiently, and to choose=
the right tool

for the job at hand (be it perl, mod_perl, or any other) without the kind o=
f off-the-cuff

general a-priori which tend to plague these discussions.



And even though our own (commercial) activities and setups do not have anyt=
hing even close

to the scope which you describe, I would like to say that the same basic pr=
inciples which

you mention in your expos=C3=A9 are just as valid when you scale-down as wh=
en you scale-up.

("--you can=E2=80=99t just throw memory, CPUs, power at a problem =E2=
=80=93 you have to

think =E2=80=93 how can I do what I need to do with the least resources..&q=
uot;)

Even when you think of a single server, or a single server rack, at any one=
period in time

there is always a practical limit as to how much memory or CPUs you can fit=
in a given

server, or how many servers you can fit in a rack, or how many additional G=
b of bandwidth

you can allocate per server, beyond which there is a sudden "quantum j=
ump" as to how

practical and cost-effective a whole project becomes.

In that sense, I particulary enjoyed your examples of the database and of t=
he additional

power line.





On 24.12.2020 02:38, James Smith wrote:

> We don=E2=80=99t use perl for everything, yes we use it for web data, =
yes we still use it as the

> glue language in a lot of cases, the most complex stuff is done with C=
(not even C++ as

> that is too slow). Others on site use Python, Java, Rust, Go, PHP, alo=
ng with looking at

> using GPUs in cases where code can be highly parallelised

>

> It is not just one application =E2=80=93 but many, many applications=
=E2=80=A6 All with a common goal of

> understanding the human genome, and using it to assist in developing n=
ew understanding and

> techniques which can advance health care.

>

> We are a very large sequencing centre (one of the largest in the world=
) =E2=80=93 what I was

> pointing out is that you can=E2=80=99t just throw memory, CPUs, power =
at a problem =E2=80=93 you have to

> think =E2=80=93 how can I do what I need to do with the least resource=
s. Rather than what

> resources can I throw at the problem.

>

> Currently we are acting as the central repository for all COVID-19 seq=
uencing in the UK,

> along with one of the largest =E2=80=9Cwet=E2=80=9D labs sequencing da=
ta for it =E2=80=93 and that is half the

> sequenced samples in the whole world. The UK is sequencing more COVID-=
19 genomes a day

> than most other countries have sequenced since the start of the pandem=
ic in Feb/Mar. This

> has lead to us discovering a new more transmissible version of the vir=
us, and it what part

> of the country the different strains are present =E2=80=93 no other co=
untry in the world has the

> information, technology or infrastructure in place to achieve this.>
>

> But this is just a small part of the genomic sequencing we are looking=
at =E2=80=93 we work on:

> * other pathogens =E2=80=93 e.g. Plasmodium (Malaria);

> * cancer genomes (and how effective drugs are);

> * are a major part of the Human Cell Atlas which is looking at how the=
expression of genes

> (in the simplest terms which ones are switched on and switched off) ar=
e different in

> different tissues;

> * sequencing the genomes of other animals to understand their evolutio=
n;

> * and looking at some other species in detail, to see what we can lear=
n from them when

> they have defective genes;

>

> Although all these are currently scaled back so that we can work relen=
tlessly to support

> the medical teams and other researchers get on top of COVID-19.

>

> What is interesting is that many of the developers we have on campus (=
well all wfh at the

> moment) are all (relatively) old as we learnt to develop code on machi=
nes with limited CPU

> and limited memory =E2=80=93 so that things had to be efficient, had t=
o be compact=E2=80=A6. And that is

> as important now as it was 20 or 30 years ago =E2=80=93 the data we ha=
ndle is going up faster than

> Moore=E2=80=99s Law! Many of us have pride in doing things as efficien=
tly as possible.

>

> It took around 10 years to sequence and assemble the first human genom=
e {well we are still

> tinkering with it and filling in the gaps} =E2=80=93 now at the instit=
ute we can sequence and

> assemble around 400 human genomes in a day =E2=80=93 to the same quali=
ty!

>

> So most of our issues are due to the scale of the problems we face =E2=
=80=93 e.g. the human genome

> has 3 billion base-pairs (A, C, G, Ts) , so normal solutions don=E2=80=
=99t scale to that (once

> many years ago we looked at setting up an Oracle database where there =
was at least 1 row

> for every base pair =E2=80=93 recording all variants (think of them as=
spelling mistakes, for

> example a T rather than an A, or an extra letter inserted or deleted) =
for that base pair=E2=80=A6

> The schema was set up =E2=80=93 and then they realised it would take 1=
2 months to load the data

> which we had then (which is probably less than a millionth of what we =
have now)!

>

> Moving compute off site is a problem as the transfer of the level of d=
ata we have would

> cause a problem =E2=80=93 you can=E2=80=99t easily move all the data t=
o the compute =E2=80=93 so you have to bring

> the compute to the data.

>

> The site I worked on before I became a more general developer was doin=
g that =E2=80=93 and the

> code that was written 12-15 years ago is actually still going strong =
=E2=80=93 it has seen a few

> changes over the year =E2=80=93 many displays have had to be redevelop=
ed as the scale of the data

> has got so big that even the summary pages we produced 10 years ago ha=
ve to be summarised

> because they are so large.

>

> *From:*Mithun Bhattacharya <get=3D"_blank">mithnb-at-gmail.com>

> *Sent:* 24 December 2020 00:06

> *To:* mod_perl list <get=3D"_blank">modperl-at-perl.apache.org>

> *Subject:* Re: Confused about two development utils [EXT]

>

> James would you be able to share more info about your setup ?

>

> 1. What exactly is your application doing which requires so much memor=
y and CPU - is it

> something like gene splicing (no i don't know much about it beyond=
Jurassic Park :D )

>

> 2. Do you feel Perl was the best choice for whatever you are doing and=
if yes then why ?

> How much of your stuff is using mod_perl considering you mentioned not=
much is web related ?

>

> 3. What are the challenges you are currently facing with your implemen=
tation ?

>

> On Wed, Dec 23, 2020 at 6:58 AM James Smith <sanger.ac.uk" target=3D"_blank">js5-at-sanger.ac.uk <mailto:mailto:js5-at-sanger.ac.uk" target=3D"_blank">js5-at-sanger.ac.uk>> >
> wrote:

>

>=C2=A0 =C2=A0 =C2=A0Oh but memory is a problem =E2=80=93 but not if you=
have just a small cluster of machines!

>

>=C2=A0 =C2=A0 =C2=A0Our boxes are larger than that =E2=80=93 but they a=
ll run virtual machine {only a small

>=C2=A0 =C2=A0 =C2=A0proportion web related} =E2=80=93 machines/memory w=
ould rapidly become in our data centre - we

>=C2=A0 =C2=A0 =C2=A0run VMWARE [995 hosts] and openstack [10,000s of ho=
sts] + a selection of large memory

>=C2=A0 =C2=A0 =C2=A0machines {measured in TBs of memory per machine }.<=
br>
>

>=C2=A0 =C2=A0 =C2=A0We would be looking at somewhere between 0.5 PB and=
1 PB of memory =E2=80=93 not just the

>=C2=A0 =C2=A0 =C2=A0price of buying that amount of memory - for many ma=
chines we need the fastest memory

>=C2=A0 =C2=A0 =C2=A0money can buy for the workload, but we would need a=
lot more CPUs then we currently

>=C2=A0 =C2=A0 =C2=A0have as we would need a larger amount of machines t=
o have 64GB virtual machines {we

>=C2=A0 =C2=A0 =C2=A0would get 2 VMs per host. We currently have approx.=
1-2000 CPUs running our hardware

>=C2=A0 =C2=A0 =C2=A0(last time I had a figure) =E2=80=93 it would proba=
bly need to go to approximately 5-10,000!

>=C2=A0 =C2=A0 =C2=A0It is not just the initial outlay but the environme=
ntal and financial cost of running

>=C2=A0 =C2=A0 =C2=A0that number of machines, and finding space to run t=
hem without putting the cooling

>=C2=A0 =C2=A0 =C2=A0costs through the roof!! That is without considerin=
g what additional constraints on

>=C2=A0 =C2=A0 =C2=A0storage having the extra machines may have (at the =
last count a year ago we had over

>=C2=A0 =C2=A0 =C2=A030 PBytes of storage on side =E2=80=93 and a large =
amount of offsite backup.

>

>=C2=A0 =C2=A0 =C2=A0We would also stretch the amount of power we can ge=
t from the national grid to power

>=C2=A0 =C2=A0 =C2=A0it all - we currently have 3 feeds from different p=
art of the national grid (we are

>=C2=A0 =C2=A0 =C2=A0fortunately in position where this is possible) and=
the dedicated link we would need

>=C2=A0 =C2=A0 =C2=A0to add more power would be at least 50 miles long!<=
br>
>

>=C2=A0 =C2=A0 =C2=A0So - managing cores/memory is vitally important to =
us =E2=80=93 moving to the cloud is an

>=C2=A0 =C2=A0 =C2=A0option we are looking at =E2=80=93 but that is more=
than 4 times the price of our onsite

>=C2=A0 =C2=A0 =C2=A0set-up (with substantial discounts from AWS) and wo=
uld require an upgrade of our

>=C2=A0 =C2=A0 =C2=A0existing link to the internet =E2=80=93 which is cu=
rrently 40Gbit of data (I think).

>

>=C2=A0 =C2=A0 =C2=A0Currently we are analysing a very large amounts of =
data directly linked to the current

>=C2=A0 =C2=A0 =C2=A0major world problem =E2=80=93 this is why the UK is=
currently being isolated as we have

>=C2=A0 =C2=A0 =C2=A0discovered and can track a new strain, in near real=
time =E2=80=93 other countries have no

>=C2=A0 =C2=A0 =C2=A0ability to do this =E2=80=93 we in a day can and do=
handle, sequence and analyse more samples

>=C2=A0 =C2=A0 =C2=A0than the whole of France has sequenced since Februa=
ry. We probably don=E2=80=99t have more of

>=C2=A0 =C2=A0 =C2=A0the new variant strain than in other areas of the w=
orld =E2=80=93 it is just that we know we

>=C2=A0 =C2=A0 =C2=A0have because of the amount of sequencing and analys=
is that we in the UK have done.

>

>=C2=A0 =C2=A0 =C2=A0*From:*Matthias Peng <hias-at-gmail.com" target=3D"_blank">pengmatthias-at-gmail.com <mailto:href=3D"mailto:pengmatthias-at-gmail.com" target=3D"_blank">pengmatthias-at-gmail=
.com
>>

>=C2=A0 =C2=A0 =C2=A0*Sent:* 23 December 2020 12:02

>=C2=A0 =C2=A0 =C2=A0*To:* mod_perl list <erl.apache.org" target=3D"_blank">modperl-at-perl.apache.org <mailto: href=3D"mailto:modperl-at-perl.apache.org" target=3D"_blank">modperl-at-perl.apa=
che.org>>

>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: Confused about two development utils=
[EXT]

>

>=C2=A0 =C2=A0 =C2=A0Today memory is not serious problem, each of our se=
rver has 64GB memory.

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forgot to add - so our FCGI servers n=
eed a lot (and I mean a lot) more memory than

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the mod_perl servers to serve the sam=
e level of content (just in case memory blows

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0up with FCGI backends)

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----Original Message-----

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: James Smith <to:js5-at-sanger.ac.uk" target=3D"_blank">js5-at-sanger.ac.uk <mailto:ref=3D"mailto:js5-at-sanger.ac.uk" target=3D"_blank">js5-at-sanger.ac.uk>&=
gt;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: 23 December 2020 11:34

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Andr=C3=A9 Warnier (tomcat/perl) =
<aw-at-ice-sa.com &l=
t;mailto:aw-at-ice-sa.coma>>>;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
.org" target=3D"_blank">modperl-at-perl.apache.org <mailto:ailto:modperl-at-perl.apache.org" target=3D"_blank">modperl-at-perl.apache.org
>>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: RE: Confused about two devel=
opment utils [EXT]

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > This costs memory, and all the =
more since many perl modules are not

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thread-safe, so if you use them in yo=
ur code, at this moment the only safe way to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0do it is to use the Apache httpd pref=
ork model. This means that each Apache httpd

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0child process has its own copy of the=
perl interpreter, which means that the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memory used by this embedded perl int=
erpreter has to be counted n times (as many

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0times as there are Apache httpd child=
processes running at any one time).

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This isn=E2=80=99t quite true - if yo=
u load modules before the process forks then they can

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cleverly share the same parts of memo=
ry. It is useful to be able to "pre-load"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0core functionality which is used acro=
ss all functions {this is the case in Linux

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyway}. It also speeds up child proc=
ess generation as the modules are already in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memory and converted to byte code.>
>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One of the great advantages of mod_pe=
rl is Apache2::SizeLimit which can blow away

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0large child process - and then if nee=
ded create new ones. This is not the case

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with some of the FCGI solutions as th=
e individual processes can grow if there is a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0memory leak or a request that retriev=
es a large amount of content (even if not

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0served), but perl can't give the =
memory back. So FCGI processes only get bigger

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and bigger and eventually blow up mem=
ory (or hit swap first)

>

>

>

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Wellcome Sanger Institute =
is operated by Genome Research=C2=A0 Limited, a charity

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registered in England with number 102=
1457 and a=C2=A0 company registered in England

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with number 2742969, whose registered=
=C2=A0 office is
oad,+London,+NW1?entry=3Dgmail&source=3Dg">215 Euston Road, London, NW1=
2

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0["noreferrer" target=3D"_blank">google.com]

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_maps_search_s-2B215-2BEusto=
n-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-26source-3Dg&d=3DDwMF=
aQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3DoH2yp0ge1ecj=
4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=3DxU3F=
4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&e=3D" rel=3D"noreferrer" target=
=3D"_blank">https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.goog=
le.com_maps_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry=
-3Dgmail-26source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8u=
clZFI0SqQnqBo&r=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_o=
gNXEVR-4ixdkrhy5khQjA&s=3DxU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&a=
mp;e=3D
>BE.

>

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Wellcome Sanger Institute =
is operated by Genome Research

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Limited, a charity registered =
in England with number 1021457 and a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0company registered in England =
with number 2742969, whose registered

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0office is ww.google.com/maps/search/215+Euston+Road,+London,+NW1?entry=3Dgmail&so=
urce=3Dg">215 Euston Road, London, NW1
2 [ rel=3D"noreferrer" target=3D"_blank">google.com]

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_maps_search_s-2B215-2BEusto=
n-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-26source-3Dg&d=3DDwMF=
aQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3DoH2yp0ge1ecj=
4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=3DxU3F=
4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&e=3D" rel=3D"noreferrer" target=
=3D"_blank">https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.goog=
le.com_maps_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry=
-3Dgmail-26source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8u=
clZFI0SqQnqBo&r=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_o=
gNXEVR-4ixdkrhy5khQjA&s=3DxU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&a=
mp;e=3D
>BE.

>

>=C2=A0 =C2=A0 =C2=A0-- The Wellcome Sanger Institute is operated by Gen=
ome Research Limited, a charity

>=C2=A0 =C2=A0 =C2=A0registered in England with number 1021457 and a com=
pany registered in England with

>=C2=A0 =C2=A0 =C2=A0number 2742969, whose registered office is =3D"https://www.google.com/maps/search/215+Euston+Road,+London,+NW1+2BE?ent=
ry=3Dgmail&source=3Dg">215 Euston Road, London, NW1 2BE
.

>

> -- The Wellcome Sanger Institute is operated by Genome Research Limite=
d, a charity

> registered in England with number 1021457 and a company registered in =
England with number

> 2742969, whose registered office is maps/search/215+Euston+Road,+London,+NW1+2BE?entry=3Dgmail&source=3Dg">=
215 Euston Road, London, NW1 2BE
.






--0000000000008a8b4d05b75972a1--

--===============1571511426==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout

--===============1571511426==--

  1. 2020-12-01 docs-owner-at-mrbrklyn.com Subject: [Hangout - NYLXS] Docs post from ruben-at-mrbrklyn.com requires
  2. 2020-12-01 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout - NYLXS] Call for Distinguished Lecturers-DEADLINE EXTENDED
  3. 2020-12-01 From: "Free Software Foundation" <info-at-fsf.org> Subject: [Hangout - NYLXS] Free Software Supporter Issue 152, December 2020
  4. 2020-12-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] You can't make this shit up...
  5. 2020-12-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Old Audio on the Net!
  6. 2020-12-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] With COVID - loose lips sink ships...
  7. 2020-12-01 Richard Stallman <rms-at-gnu.org> Re: [Hangout - NYLXS] Can folks see this image?
  8. 2020-12-02 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout - NYLXS] Can folks see this image?
  9. 2020-12-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Privacy rights under Halacha
  10. 2020-12-02 Yunxiang Li via artix-general <artix-general-at-artixlinux.org> Subject: [Hangout - NYLXS] [artix-general] Fixes for dbus-s6
  11. 2020-12-02 From: =?utf-8?Q?Zo=C3=AB_Kooyman=2C_FSF?= <info-at-fsf.org> Subject: [Hangout - NYLXS] 35 years of freedom and memories from the FSF
  12. 2020-12-02 NCPA eCommunications <ncpa.ecommunications-at-ncpanet.org> Subject: [Hangout - NYLXS] Thursday webinar will help increase your vaccine
  13. 2020-12-02 From: "Greg Farough, DbD" <info-at-defectivebydesign.org> Subject: [Hangout - NYLXS] International Day Against DRM (IDAD) is almost
  14. 2020-12-02 From: "[RSS/Feed] nixCraft: Linux Tips, Hacks, Tutorials, Subject: [Hangout - NYLXS] nixCraft Linux / UNIX Newsletter
  15. 2020-12-02 Dudemanguy via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] Fixes for dbus-s6
  16. 2020-12-02 Yunxiang Li via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] Fixes for dbus-s6
  17. 2020-12-02 Dudemanguy via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] Fixes for dbus-s6
  18. 2020-12-04 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Trump was aracist for his fear of Muslim
  19. 2020-12-04 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Vaccine roll out problems..
  20. 2020-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Things you could be doing with your life... -
  21. 2020-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] Photo Journal of SOHO from today - Note how
  22. 2020-12-05 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] prayers --
  23. 2020-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Fwd: Planned obsolescence in computing: examples
  24. 2020-12-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] china military might rapidy growing during covid
  25. 2020-12-07 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #489 - Meta Advent
  26. 2020-12-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Architect of Florida's coronavirus dashboard says
  27. 2020-12-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Collapsing Airline business
  28. 2020-12-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Dylan Copyrights sold for millions...
  29. 2020-12-08 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Hangout - NYLXS] Dylan Copyrights sold for millions...
  30. 2020-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] NEW MTA slush fund... on like deliveries
  31. 2020-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] China has a vaccination also... and they are
  32. 2020-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] The shortage of emergency healthcare supplyand
  33. 2020-12-09 Lucy Phipps <landfillbaby69-at-gmail.com> Subject: [Hangout - NYLXS] [png-mng-implement] [PATCH] pngcheck: Output zlib
  34. 2020-12-09 Lucy Phipps <landfillbaby69-at-gmail.com> Re: [Hangout - NYLXS] [png-mng-implement] [PATCH] pngcheck: check
  35. 2020-12-09 Lucy Phipps <landfillbaby69-at-gmail.com> Subject: [Hangout - NYLXS] [png-mng-implement] [PATCH] pngcheck: check 4th
  36. 2020-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] NYC Freelancers on the endge
  37. 2020-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] New York just never learns - New York City
  38. 2020-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] China's Banking system moving into the primary
  39. 2020-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Future Free Phone OS that might not track you
  40. 2020-12-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] Future Free Phone OS that might not track you
  41. 2020-12-09 Javier via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] Fixes for dbus-s6
  42. 2020-12-09 Dudemanguy via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] Fixes for dbus-s6
  43. 2020-12-09 Javier via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] Was pandoc-bin dropped from
  44. 2020-12-09 Javier via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] [artix-gen] python2-pillow
  45. 2020-12-09 Javier via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] Fixes for dbus-s6
  46. 2020-12-09 From: "Donald Robertson, III, FSF" <info-at-fsf.org> Subject: [Hangout - NYLXS] The road to software freedom is paved with
  47. 2020-12-10 From: "Xavier B. via artix-general" <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] Was pandoc-bin dropped from
  48. 2020-12-10 From: "Dana Morgenstein, FSF" <info-at-fsf.org> Subject: [Hangout - NYLXS] In-depth free software news: Read the fall
  49. 2020-12-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Vaccine Madness
  50. 2020-12-13 John Emmas <john-at-creativepost.co.uk> Re: [Hangout - NYLXS] [png-mng-implement] Do PNG files come in
  51. 2020-12-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] City continues to die
  52. 2020-12-13 Miss Belmar Princess <missbelmar-at-aol.com> Subject: [Hangout - NYLXS] THANK YOU!
  53. 2020-12-13 Ben Bullock <benkasminbullock-at-gmail.com> Subject: [Hangout - NYLXS] [png-mng-implement] What is png_get_palette_max
  54. 2020-12-13 J Decker <d3ck0r-at-gmail.com> Re: [Hangout - NYLXS] [png-mng-implement] Do PNG files come in
  55. 2020-12-13 Greg Roelofs <newt-at-pobox.com> Re: [Hangout - NYLXS] [png-mng-implement] [PATCH] pngcheck: check
  56. 2020-12-14 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #490 - Elevator Pitch Day
  57. 2020-12-13 Alexandre Oliva <lxoliva-at-fsfla.org> Subject: [Hangout - NYLXS] GNU Linux-libre 5.10-gnu
  58. 2020-12-14 Ben Bullock <benkasminbullock-at-gmail.com> Re: [Hangout - NYLXS] [png-mng-implement] What is
  59. 2020-12-14 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #490 - Elevator Pitch Day
  60. 2020-12-14 From: "TheaterMania" <donotreply-at-email.theatermania.com> Subject: [Hangout - NYLXS] Concerts celebrating Gershwin, Rodgers,
  61. 2020-12-14 John Emmas <john-at-creativepost.co.uk> Re: [Hangout - NYLXS] [png-mng-implement] Do PNG files come in
  62. 2020-12-14 Sergey Poznyakoff <gray-at-gnu.org.ua> Subject: [Hangout - NYLXS] pies-1.5 released [stable]
  63. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] The Chinese Virus
  64. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] glass
  65. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] The MTA as a WUHAN-19 Vector
  66. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [ Docs ] The MTA as a WUHAN-19 Vector
  67. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] [ Docs ] The MTA as a WUHAN-19 Vector
  68. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Israeli Uni RAM ->WIFI that steals data
  69. 2020-12-15 NYOUG <execdir-at-nyoug.org> Subject: [Hangout - NYLXS] Upcoming Events for Oracle Professionals
  70. 2020-12-15 Techno <techno6-at-glib.com> Re: [Hangout - NYLXS] [Gimp-user] Help!
  71. 2020-12-14 Javier via artix-general <artix-general-at-artixlinux.org> Subject: [Hangout - NYLXS] [artix-general] re2 package requires update to
  72. 2020-12-15 From: =?utf-8?Q?Zo=C3=AB_Kooyman=2C_FSF?= <info-at-fsf.org> Subject: [Hangout - NYLXS] Register for LibrePlanet 2021 and help us to
  73. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Funding Local Government on the post-COVID-19 Age
  74. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] findiing teachers with covid-19
  75. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Israel and Sudan and terrorism...
  76. 2020-12-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] UAE via Tel Aviva - Easy Peasy
  77. 2020-12-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] You need to watch this thing
  78. 2020-12-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Fwd: Winter storm preparation.
  79. 2020-12-16 Javier via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] re2 package requires update
  80. 2020-12-15 Liz Moore <lizmoorerph-at-gmail.com> Subject: [Hangout - NYLXS] Vaccine
  81. 2020-12-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Threatening the public with a full shutdown
  82. 2020-12-16 From: "Greg Farough, DbD" <info-at-defectivebydesign.org> Subject: [Hangout - NYLXS] IDAD 2020 sent Netflix and DRM a message
  83. 2020-12-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Bingo - Pardon Snowden!
  84. 2020-12-17 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Previous Gneerations..
  85. 2020-12-17 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] Previous Gneerations..
  86. 2020-12-17 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] Previous Gneerations..
  87. 2020-12-17 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] Previous Gneerations..
  88. 2020-12-18 From: "[RSS/Feed] nixCraft: Linux Tips, Hacks, Tutorials, Subject: [Hangout - NYLXS] nixCraft Linux / UNIX Newsletter
  89. 2020-12-18 NCPA eCommunications <ncpa.ecommunications-at-ncpanet.org> Subject: [Hangout - NYLXS] Grab reduced price on January Ownership Workshop
  90. 2020-12-20 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  91. 2020-12-20 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  92. 2020-12-20 Tom Browder <tom.browder-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  93. 2020-12-20 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  94. 2020-12-20 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  95. 2020-12-20 John Dunlap <John-at-lariat.co> Re: [Hangout - NYLXS] suggestions for perl as web development
  96. 2020-12-20 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  97. 2020-12-20 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] suggestions for perl as web development
  98. 2020-12-20 Tom Browder <tom.browder-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  99. 2020-12-20 Steven Lembark <lembark-at-wrkhors.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  100. 2020-12-20 Steven Lembark <lembark-at-wrkhors.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  101. 2020-12-19 Rabbinical Seminary of America/Yeshiva Chofetz Chaim Subject: [Hangout - NYLXS] Time is Running Out! Please Join Us in Expressing
  102. 2020-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Vaccine explanations by my favorite PA's who are
  103. 2020-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] we are in serious trouble...
  104. 2020-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] This is worth understanding...
  105. 2020-12-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Treatment Failure
  106. 2020-12-21 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #491 - Both CPAN RT and the CPAN
  107. 2020-12-20 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  108. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  109. 2020-12-22 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  110. 2020-12-22 John Dunlap <John-at-lariat.co> Re: [Hangout - NYLXS] suggestions for perl as web development
  111. 2020-12-22 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] suggestions for perl as web development
  112. 2020-12-22 Matthias Peng <pengmatthias-at-gmail.com> Subject: [Hangout - NYLXS] Confused about two development utils
  113. 2020-12-22 John Dunlap <John-at-lariat.co> Re: [Hangout - NYLXS] suggestions for perl as web development
  114. 2020-12-21 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Don't use session hashes [EXT]
  115. 2020-12-22 From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat/perl=29?= <aw-at-ice-sa.com> Re: [Hangout - NYLXS] Confused about two development utils
  116. 2020-12-21 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] suggestions for perl as web development
  117. 2020-12-21 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] suggestions for perl as web development
  118. 2020-12-21 Vincent Veyron <vv.lists-at-wanadoo.fr> Subject: [Hangout - NYLXS] Don't use session hashes
  119. 2020-12-21 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  120. 2020-12-21 Vincent Veyron <vv.lists-at-wanadoo.fr> Re: [Hangout - NYLXS] suggestions for perl as web development
  121. 2020-12-20 Vincent Veyron <vv.lists-at-wanadoo.fr> Re: [Hangout - NYLXS] suggestions for perl as web development
  122. 2020-12-20 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  123. 2020-12-20 Vincent Veyron <vv.lists-at-wanadoo.fr> Re: [Hangout - NYLXS] suggestions for perl as web development
  124. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  125. 2020-12-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Our friends who we depend on for medical
  126. 2020-12-22 From: =?utf-8?Q?Zo=C3=AB_Kooyman=2C_FSF?= <info-at-fsf.org> Subject: [Hangout - NYLXS] Help us set high priorities for 2021: Send input
  127. 2020-12-22 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Answer to Asking about comparison
  128. 2020-12-22 From: "Rick Strong" <rnstrong-at-primus.ca> Re: [Hangout - NYLXS] [Gimp-user] Answer to Asking about comparison
  129. 2020-12-22 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Answer to Asking about comparison
  130. 2020-12-22 From: "Rick Strong" <rnstrong-at-primus.ca> Re: [Hangout - NYLXS] [Gimp-user] Answer to Asking about comparison
  131. 2020-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] The Panic is setting in!!!
  132. 2020-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] No end to Government Survalence
  133. 2020-12-23 Sandhya <sandhya.pawar03-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  134. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  135. 2020-12-23 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  136. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  137. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  138. 2020-12-23 From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat/perl=29?= <aw-at-ice-sa.com> Re: [Hangout - NYLXS] Confused about two development utils
  139. 2020-12-22 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  140. 2020-12-22 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  141. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  142. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  143. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  144. 2020-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Fwd: Winter storm preparation.
  145. 2020-12-23 Sergey Poznyakoff <gray-at-gnu.org.ua> Subject: [Hangout - NYLXS] mailutils-3.11 released [stable]
  146. 2020-12-23 Sergey Poznyakoff <gray-at-gnu.org.ua> Subject: [Hangout - NYLXS] gdbm-1.19 released [stable]
  147. 2020-12-23 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  148. 2020-12-23 Nuno Semedo via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Help me with the interface
  149. 2020-12-22 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Colour Palette
  150. 2020-12-21 Joshua Oxley via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Gaussian blur confusion
  151. 2020-12-22 Ofnuts via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Gaussian blur confusion
  152. 2020-12-22 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Gaussian blur confusion
  153. 2020-12-22 Peter Wells <mail-at-organbuilder.com> Subject: [Hangout - NYLXS] [Gimp-user] Colour Palette
  154. 2020-12-19 From: "Rick Strong" <rnstrong-at-primus.ca> Re: [Hangout - NYLXS] [Gimp-user] Images different in other editors
  155. 2020-12-18 Richard Kimber via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Images much darker in other editors
  156. 2020-12-19 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Images much darker in other
  157. 2020-12-18 Nicholas Perks via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Feedback
  158. 2020-12-18 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Images much darker in other
  159. 2020-12-17 Nicholas Perks via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Feedback
  160. 2020-12-16 nick glos via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] gimp-user-list Digest, Vol 111,
  161. 2020-12-16 Pat David via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Feedback
  162. 2020-12-11 ShiroYuki Mot via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] open multi tiff files in script-fu
  163. 2020-12-07 Cliff Pratt via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  164. 2020-12-13 Nicholas Perks via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Help!
  165. 2020-12-13 Francesco Angioni via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] problem with installation help file
  166. 2020-12-07 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  167. 2020-12-05 Partha Bagchi via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  168. 2020-12-05 Partha Bagchi via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] H E L P!
  169. 2020-12-05 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  170. 2020-12-05 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] H E L P!
  171. 2020-12-15 nick glos via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] gimp-user-list Digest, Vol 111,
  172. 2020-12-15 Nicholas Perks via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Feedback
  173. 2020-12-05 Ed Prothero via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] H E L P
  174. 2020-12-05 Partha Bagchi via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] H E L P!
  175. 2020-12-04 Mark Morin <mdmpsyd-at-gwi.net> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  176. 2020-12-04 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  177. 2020-12-04 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  178. 2020-12-04 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  179. 2020-12-03 Cliff Pratt via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  180. 2020-12-04 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] GIMP 2.10 .xcf files can't open
  181. 2020-12-04 From: "Rick Strong" <rnstrong-at-primus.ca> Re: [Hangout - NYLXS] [Gimp-user] Image Compression
  182. 2020-12-03 Dave Stevens <geek-at-uniserve.com> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  183. 2020-12-03 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  184. 2020-12-03 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  185. 2020-12-03 Partha Bagchi via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  186. 2020-12-03 Thomas Liljenstam via ekiga-list <ekiga-list-at-gnome.org> Re: [Hangout - NYLXS] [Ekiga-list] Ekiga 4.0.1 - Assertion fail:
  187. 2020-12-03 Jop Huttenhuis via ekiga-list <ekiga-list-at-gnome.org> Subject: [Hangout - NYLXS] [Ekiga-list] Ekiga 4.0.1 - Assertion fail:
  188. 2020-12-03 From: "Dr. Jason L. Amerson" <drjason-at-alphagenius.org> Re: [Hangout - NYLXS] [Gimp-user] Image Compression
  189. 2020-12-03 From: "Dr. Jason L. Amerson" <drjason-at-alphagenius.org> Re: [Hangout - NYLXS] [Gimp-user] Image Compression
  190. 2020-12-03 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  191. 2020-12-03 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  192. 2020-12-02 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  193. 2020-12-02 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  194. 2020-12-02 Partha Bagchi via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  195. 2020-12-02 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  196. 2020-12-02 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  197. 2020-12-02 Partha Bagchi via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  198. 2020-12-02 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  199. 2020-12-02 Partha Bagchi via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  200. 2020-12-02 Rick Kline <rick-at-kline.ms> Subject: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image files
  201. 2020-12-15 Ken Moffat via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] gimp-user-list Digest, Vol 111,
  202. 2020-12-17 Pat David via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Feedback
  203. 2020-12-02 Techno <techno6-at-glib.com> Re: [Hangout - NYLXS] [Gimp-user] GIMP 2.10 .xcf files can't open
  204. 2020-12-02 Jason Amerson via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Image Compression
  205. 2020-12-04 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  206. 2020-12-04 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  207. 2020-12-02 From: =?UTF-8?B?w5h5dmluZCBLb2zDpXM=?= <pippin-at-gimp.org> Re: [Hangout - NYLXS] [Gimp-user] Image Compression
  208. 2020-12-02 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Image Compression
  209. 2020-12-02 Cliff Pratt via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] GIMP 2.10 .xcf files can't open
  210. 2020-12-02 Cliff Pratt via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Image Compression
  211. 2020-12-04 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Opening uncompressed NASA image
  212. 2020-12-04 Richard Kimber via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Images different in other editors
  213. 2020-12-23 David Cantrell <david-at-cantrell.org.uk> Re: [Hangout - NYLXS] CFP NY.PM Technical Meetup
  214. 2020-12-23 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] CFP NY.PM Technical Meetup
  215. 2020-12-24 Alexandre Prokoudine via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Answer to Asking about comparison
  216. 2020-12-24 Alexandre Prokoudine via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Answer to Asking about comparison
  217. 2020-12-24 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Answer to Asking about comparison
  218. 2020-12-23 klausgoelker--- via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Answer to Asking about comparison
  219. 2020-12-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Anyone have a recommendation for a good source
  220. 2020-12-24 Simon Sobisch <simonsobisch-at-gnu.org> Subject: [Hangout - NYLXS] Release of GnuCOBOL 3.1.2
  221. 2020-12-24 IEEE Engineering in Medicine and Biology Society <m.markowycz-at-ieee.org> Subject: [Hangout - NYLXS] A Special Message from the EMBS President,
  222. 2020-12-25 From: "S." <sman356-at-yahoo.com> Re: [Hangout - NYLXS] Release of GnuCOBOL 3.1.2 | I spent alotta
  223. 2020-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] Release of GnuCOBOL 3.1.2 | I spent alotta
  224. 2020-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Fear Mongering never ends
  225. 2020-12-23 Nuno Semedo via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Help me with the interface
  226. 2020-12-25 Ofnuts via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] [Animations] How to merge down
  227. 2020-12-24 R45XvezA via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] [Animations] How to merge down
  228. 2020-12-25 Ofnuts via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Procedure Plug-in
  229. 2020-12-25 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Help me with the interface
  230. 2020-12-24 David Appleyard via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Procedure Plug-in
  231. 2020-12-24 Nicholas Perks via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] Feedback
  232. 2020-12-24 David Appleyard via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] Procedure Plug-in
  233. 2020-12-24 Liam R E Quin <liam-at-holoweb.net> Re: [Hangout - NYLXS] [Gimp-user] Help me with the interface
  234. 2020-12-23 Rick Kline <rick-at-kline.ms> Re: [Hangout - NYLXS] [Gimp-user] Help me with the interface
  235. 2020-12-26 Sandhya <sandhya.pawar03-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  236. 2020-12-26 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  237. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  238. 2020-12-25 From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat/perl=29?= <aw-at-ice-sa.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  239. 2020-12-26 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  240. 2020-12-26 Sandhya <sandhya.pawar03-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  241. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  242. 2020-12-25 From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat/perl=29?= <aw-at-ice-sa.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  243. 2020-12-23 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  244. 2020-12-23 Sandhya <sandhya.pawar03-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  245. 2020-12-23 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  246. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  247. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  248. 2020-12-23 From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat/perl=29?= <aw-at-ice-sa.com> Re: [Hangout - NYLXS] Confused about two development utils
  249. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  250. 2020-12-22 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] unsubscribe
  251. 2020-12-22 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  252. 2020-12-22 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  253. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  254. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  255. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  256. 2020-12-26 From: "S." <sman356-at-yahoo.com> Re: [Hangout - NYLXS] Release of GnuCOBOL 3.1.2 | I spent alotta
  257. 2020-12-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Edward Snowden
  258. 2020-12-28 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Snoden pardon
  259. 2020-12-28 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout - NYLXS] [Perlweekly] #492 - Perl Steering Council Election
  260. 2020-12-28 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Zoom, Google, Facebook spyware
  261. 2020-12-28 From: "Humble Bundle" <contact-at-mailer.humblebundle.com> Subject: [Hangout - NYLXS] Learn what Sudo does and other Linux lexicons!
  262. 2020-12-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] SNoden and the EFF
  263. 2020-12-29 Nate Lally <nate.lally-at-gmail.com> Re: [Hangout - NYLXS] CFP NY.PM Technical Meetup
  264. 2020-12-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] cellphone mix up
  265. 2020-12-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] A survey the media distorions and the price we
  266. 2020-12-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] trust your friends in China - Free Medical
  267. 2020-12-29 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout - NYLXS] [ Docs ] trust your friends in China - Free
  268. 2020-12-29 From: "S." <sman356-at-yahoo.com> Subject: [Hangout - NYLXS] Fw: Plastic coffins | | True report ?
  269. 2020-12-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Continuation of the Chinese political problem and
  270. 2020-12-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Swim Class on Zoom - Back Stroke it Baby
  271. 2020-12-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] COVID - the Rich get richer and leave the city
  272. 2020-12-29 Luis Falcon <falcon-at-gnuhealth.org> Re: [Hangout - NYLXS] [Health] Set another Default value on
  273. 2020-12-29 From: "Odile C. Kamno" <christelia3-at-hotmail.com> Subject: [Hangout - NYLXS] [Health] Set another Default value on nationality
  274. 2020-12-29 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] Fw: Plastic coffins | | True report ?
  275. 2020-12-30 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] COVID-19 causes hysteria in Congressional Alien
  276. 2020-12-30 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] CEOs and Economic results of COVID-19 really a
  277. 2020-12-30 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] Pharmacists
  278. 2020-12-29 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2361-1: important: Security
  279. 2020-12-29 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2359-1: important: Security
  280. 2020-12-29 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2360-1: important: Security
  281. 2020-12-28 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2357-1: important: Security
  282. 2020-12-28 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2350-1: moderate: Security
  283. 2020-12-28 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2351-1: moderate: Security
  284. 2020-12-27 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2349-1: moderate: Security
  285. 2020-12-27 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2348-1: moderate: Security
  286. 2020-12-27 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2344-1: Security update for
  287. 2020-12-26 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2336-1: moderate: Security
  288. 2020-12-26 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2343-1: important: Security
  289. 2020-12-26 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2334-1: important: Security
  290. 2020-12-26 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2333-1: important: Security
  291. 2020-12-26 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2332-1: important: Security
  292. 2020-12-25 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2325-1: critical: Security
  293. 2020-12-25 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2324-1: critical: Security
  294. 2020-12-22 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2317-1: critical: Security
  295. 2020-12-22 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2318-1: critical: Security
  296. 2020-12-22 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2317-1: critical: Security
  297. 2020-12-22 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2313-1: moderate: Security
  298. 2020-12-26 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2337-1: moderate: Security
  299. 2020-12-26 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2331-1: moderate: Security
  300. 2020-12-25 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2327-1: important: Security
  301. 2020-12-22 opensuse-security-at-opensuse.org Subject: [Hangout - NYLXS] openSUSE-SU-2020:2314-1: moderate: Security
  302. 2020-12-30 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Digital Mirrors with Adrino Boards
  303. 2020-12-30 From: "Geoffrey Knauth, FSF" <info-at-fsf.org> Subject: [Hangout - NYLXS] FSF fights to secure software freedom for future
  304. 2020-12-30 From: "S." <sman356-at-yahoo.com> Re: [Hangout - NYLXS] Plastic coffins | | True report ? | | | 29.95
  305. 2020-12-30 Rabbinical Seminary of America/Yeshiva Chofetz Chaim Subject: [Hangout - NYLXS] DEADLINE IN A FEW HOURS! In Lieu of Our Dinner...
  306. 2020-12-31 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Hackings and the Vaccine roll out
  307. 2020-12-31 From: "achmil" <achmil-at-free.fr> Subject: [Hangout - NYLXS] [Gimp-user] bugs Gimp 2.10.22
  308. 2020-12-31 dboland9 via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] LED white christmas lights effect
  309. 2020-12-31 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout - NYLXS] Career change.... Fwd: 2021 Fossil Explainer
  310. 2020-12-31 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Hangout - NYLXS] Collapse of intellectual culture... this is how
  311. 2020-12-31 Jacques Deguest <jack-at-deguest.jp> Subject: [Hangout - NYLXS] How to create an APR::SockAddr object
  312. 2020-12-30 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  313. 2020-12-30 Tom Browder <tom.browder-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  314. 2020-12-29 Adam Prime <adam.prime-at-utoronto.ca> Re: [Hangout - NYLXS] HTML template for MP2
  315. 2020-12-29 Matthias Peng <pengmatthias-at-gmail.com> Subject: [Hangout - NYLXS] HTML template for MP2
  316. 2020-12-31 Jacques Deguest <jack-at-deguest.jp> Subject: [Hangout - NYLXS] How to create an APR::SockAddr object
  317. 2020-12-30 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  318. 2020-12-30 Tom Browder <tom.browder-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  319. 2020-12-29 Matthias Peng <pengmatthias-at-gmail.com> Subject: [Hangout - NYLXS] HTML template for MP2
  320. 2020-12-26 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  321. 2020-12-29 Adam Prime <adam.prime-at-utoronto.ca> Re: [Hangout - NYLXS] HTML template for MP2
  322. 2020-12-30 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] suggestions for perl as web development
  323. 2020-12-31 Jacques Deguest <jack-at-deguest.jp> Subject: [Hangout - NYLXS] How to create an APR::SockAddr object
  324. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  325. 2020-12-25 From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat/perl=29?= <aw-at-ice-sa.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  326. 2020-12-23 Sandhya <sandhya.pawar03-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  327. 2020-12-23 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  328. 2020-12-23 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  329. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  330. 2020-12-22 Matthias Peng <pengmatthias-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  331. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  332. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  333. 2020-12-22 Mithun Bhattacharya <mithnb-at-gmail.com> Re: [Hangout - NYLXS] Confused about two development utils
  334. 2020-12-23 James Smith <js5-at-sanger.ac.uk> Re: [Hangout - NYLXS] Confused about two development utils [EXT]
  335. 2020-12-23 From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat/perl=29?= <aw-at-ice-sa.com> Re: [Hangout - NYLXS] Confused about two development utils
  336. 2020-12-29 Nate Lally <nate.lally-at-gmail.com> Re: [Hangout - NYLXS] CFP NY.PM Technical Meetup
  337. 2020-12-28 Pen Guin via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] How to compile a vala GIMP plugin on
  338. 2020-12-27 Pen Guin via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] How to compile a vala plugin on
  339. 2020-12-26 flexible fotography via gimp-user-list <gimp-user-list-at-gnome.org> Subject: [Hangout - NYLXS] [Gimp-user] configuring GIMP 2.8 for Windows 10
  340. 2020-12-27 Alexandre Prokoudine via gimp-user-list <gimp-user-list-at-gnome.org> Re: [Hangout - NYLXS] [Gimp-user] configuring GIMP 2.8 for Windows
  341. 2020-12-16 Javier via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] re2 package requires update
  342. 2020-12-16 Javier via artix-general <artix-general-at-artixlinux.org> Re: [Hangout - NYLXS] [artix-general] re2 package requires update
  343. 2020-12-29 Nate Lally <nate.lally-at-gmail.com> Re: [Hangout - NYLXS] CFP NY.PM Technical Meetup
  344. 2020-12-24 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout - NYLXS] CFP NY.PM Technical Meetup

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!