Mon Dec 2 23:46:20 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-12-02 | 2024-11-02 | 2024-10-02 | 2024-09-02 | 2024-08-02 | 2024-07-02 | 2024-06-02 | 2024-05-02 | 2024-04-02 | 2024-03-02 | 2024-02-02 | 2024-01-02 | 2023-12-02 | 2023-11-02 | 2023-10-02 | 2023-09-02 | 2023-08-02 | 2023-07-02 | 2023-06-02 | 2023-05-02 | 2023-04-02 | 2023-03-02 | 2023-02-02 | 2023-01-02 | 2022-12-02 | 2022-11-02 | 2022-10-02 | 2022-09-02 | 2022-08-02 | 2022-07-02 | 2022-06-02 | 2022-05-02 | 2022-04-02 | 2022-03-02 | 2022-02-02 | 2022-01-02 | 2021-12-02 | 2021-11-02 | 2021-10-02 | 2021-09-02 | 2021-08-02 | 2021-07-02 | 2021-06-02 | 2021-05-02 | 2021-04-02 | 2021-03-02 | 2021-02-02 | 2021-01-02 | 2020-12-02 | 2020-11-02 | 2020-10-02 | 2020-09-02 | 2020-08-02 | 2020-07-02 | 2020-06-02 | 2020-05-02 | 2020-04-02 | 2020-03-02 | 2020-02-02 | 2020-01-02 | 2019-12-02 | 2019-11-02 | 2019-10-02 | 2019-09-02 | 2019-08-02 | 2019-07-02 | 2019-06-02 | 2019-05-02 | 2019-04-02 | 2019-03-02 | 2019-02-02 | 2019-01-02 | 2018-12-02 | 2018-11-02 | 2018-10-02 | 2018-09-02 | 2018-08-02 | 2018-07-02 | 2018-06-02 | 2018-05-02 | 2018-04-02 | 2018-03-02 | 2018-02-02 | 2018-01-02 | 2017-12-02 | 2017-11-02 | 2017-10-02 | 2017-09-02 | 2017-08-02 | 2017-07-02 | 2017-06-02 | 2017-05-02 | 2017-04-02 | 2017-03-02 | 2017-02-02 | 2017-01-02 | 2016-12-02 | 2016-11-02 | 2016-10-02 | 2016-09-02 | 2016-08-02 | 2016-07-02 | 2016-06-02 | 2016-05-02 | 2016-04-02 | 2016-03-02 | 2016-02-02 | 2016-01-02 | 2015-12-02 | 2015-11-02 | 2015-10-02 | 2015-09-02 | 2015-08-02 | 2015-07-02 | 2015-06-02 | 2015-05-02 | 2015-04-02 | 2015-03-02 | 2015-02-02 | 2015-01-02 | 2014-12-02 | 2014-11-02 | 2014-10-02 | 2014-09-02 | 2014-08-02 | 2014-07-02 | 2014-06-02 | 2014-05-02 | 2014-04-02 | 2014-03-02 | 2014-02-02 | 2014-01-02 | 2013-12-02 | 2013-11-02 | 2013-10-02 | 2013-09-02 | 2013-08-02 | 2013-07-02 | 2013-06-02 | 2013-05-02 | 2013-04-02 | 2013-03-02 | 2013-02-02 | 2013-01-02 | 2012-12-02 | 2012-11-02 | 2012-10-02 | 2012-09-02 | 2012-08-02 | 2012-07-02 | 2012-06-02 | 2012-05-02 | 2012-04-02 | 2012-03-02 | 2012-02-02 | 2012-01-02 | 2011-12-02 | 2011-11-02 | 2011-10-02 | 2011-09-02 | 2011-08-02 | 2011-07-02 | 2011-06-02 | 2011-05-02 | 2011-04-02 | 2011-03-02 | 2011-02-02 | 2011-01-02 | 2010-12-02 | 2010-11-02 | 2010-10-02 | 2010-09-02 | 2010-08-02 | 2010-07-02 | 2010-06-02 | 2010-05-02 | 2010-04-02 | 2010-03-02 | 2010-02-02 | 2010-01-02 | 2009-12-02 | 2009-11-02 | 2009-10-02 | 2009-09-02 | 2009-08-02 | 2009-07-02 | 2009-06-02 | 2009-05-02 | 2009-04-02 | 2009-03-02 | 2009-02-02 | 2009-01-02 | 2008-12-02 | 2008-11-02 | 2008-10-02 | 2008-09-02 | 2008-08-02 | 2008-07-02 | 2008-06-02 | 2008-05-02 | 2008-04-02 | 2008-03-02 | 2008-02-02 | 2008-01-02 | 2007-12-02 | 2007-11-02 | 2007-10-02 | 2007-09-02 | 2007-08-02 | 2007-07-02 | 2007-06-02 | 2007-05-02 | 2007-04-02 | 2007-03-02 | 2007-02-02 | 2007-01-02 | 2006-12-02 | 2006-11-02 | 2006-10-02 | 2006-09-02 | 2006-08-02 | 2006-07-02 | 2006-06-02 | 2006-05-02 | 2006-04-02 | 2006-03-02 | 2006-02-02 | 2006-01-02 | 2005-12-02 | 2005-11-02 | 2005-10-02 | 2005-09-02 | 2005-08-02 | 2005-07-02 | 2005-06-02 | 2005-05-02 | 2005-04-02 | 2005-03-02 | 2005-02-02 | 2005-01-02 | 2004-12-02 | 2004-11-02 | 2004-10-02 | 2004-09-02 | 2004-08-02 | 2004-07-02 | 2004-06-02 | 2004-05-02 | 2004-04-02 | 2004-03-02 | 2004-02-02 | 2004-01-02 | 2003-12-02 | 2003-11-02 | 2003-10-02 | 2003-09-02 | 2003-08-02 | 2003-07-02 | 2003-06-02 | 2003-05-02 | 2003-04-02 | 2003-03-02 | 2003-02-02 | 2003-01-02 | 2002-12-02 | 2002-11-02 | 2002-10-02 | 2002-09-02 | 2002-08-02 | 2002-07-02 | 2002-06-02 | 2002-05-02 | 2002-04-02 | 2002-03-02 | 2002-02-02 | 2002-01-02 | 2001-12-02 | 2001-11-02 | 2001-10-02 | 2001-09-02 | 2001-08-02 | 2001-07-02 | 2001-06-02 | 2001-05-02 | 2001-04-02 | 2001-03-02 | 2001-02-02 | 2001-01-02 | 2000-12-02 | 2000-11-02 | 2000-10-02 | 2000-09-02 | 2000-08-02 | 2000-07-02 | 2000-06-02 | 2000-05-02 | 2000-04-02 | 2000-03-02 | 2000-02-02 | 2000-01-02 | 1999-12-02

Key: Value:

Key: Value:

MESSAGE
DATE 2020-12-26
FROM Sandhya
SUBJECT Re: [Hangout - NYLXS] Confused about two development utils [EXT]
From hangout-bounces-at-nylxs.com Sat Dec 26 03:23:08 2020
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 D720D16403F;
Sat, 26 Dec 2020 03:23:07 -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 543E516403A; Sat, 26 Dec 2020 03:23:01 -0500 (EST)
Resent-From: Ruben Safir
Resent-Date: Sat, 26 Dec 2020 03:23:01 -0500
Resent-Message-ID: <20201226082301.GB4921-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 (unknown [3.227.148.255])
by mrbrklyn.com (Postfix) with ESMTP id AFE0116400B
for ; Sat, 26 Dec 2020 02:23:39 -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 1E9C144D6F
for ; Sat, 26 Dec 2020 07:23:19 +0000 (UTC)
Received: (qmail 90542 invoked by uid 500); 26 Dec 2020 07:23:18 -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 90531 invoked by uid 99); 26 Dec 2020 07:23:17 -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 07:23:17 +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 151261FF3A1
for ; Sat, 26 Dec 2020 07:23:17 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org
X-Spam-Flag: NO
X-Spam-Score: 0.249
X-Spam-Level:
X-Spam-Status: No, score=0.249 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 wce80GLIEaHO for ;
Sat, 26 Dec 2020 07:23:14 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.167.44;
helo=mail-lf1-f44.google.com; envelope-from=sandhya.pawar03-at-gmail.com;
receiver=
Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com
[209.85.167.44])
by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with
ESMTPS id 6E7BEBC95A
for ; Sat, 26 Dec 2020 07:23:13 +0000 (UTC)
Received: by mail-lf1-f44.google.com with SMTP id y19so13084358lfa.13
for ; Fri, 25 Dec 2020 23:23:13 -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;
bh=lvINCV2sfmvENEIFaJkQa0qMj0Fc/8ZepnGj0V6rKjk=;
b=avURZ5eBPSIxOdXBb6iu3P03esCF/OqupDsnTAGHO5qcpT9GAgdmWtuCdVf+KlWE+Z
AOTeDCUw81Zq8s0XXfFcXng+9bydp87MdDz/uGu8suAdDKHWARhPsI0mz7btkzPt+53G
rTg3zqxlO0VNPO4zybtREQVlPYVM+HpE/HggaZ1ClCUr5fYI1B3v0QDsZlNouYs4I+qB
KJNIKvt0ITOJSsrdsj7oVYn5sSqtkv4isvOclDgK5A3kFOhpjyC7K/0Nx7Lqjwg2eK8N
4zrfsA9/lnR6DtW1v8/d3mt0RfpDZ/E/2/JRNFOOyuiBoBnzRWxpRYKweXU87Gc8gnTh
bA9A==
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;
bh=lvINCV2sfmvENEIFaJkQa0qMj0Fc/8ZepnGj0V6rKjk=;
b=fU8Q2wNS2kX51OGV7WQNHjmh+4Eq5U2G2DuIgGR54hvB4MvFXQQ3WtDQzydpC6vrWE
bC5CLTG+amWFDfDp1FOuCoLo/rFm73btoU1d1495Akq++kGFGe+xBev2iT2ZNBK1qxGX
dZPdOw014kx8ymaMYB3rzhVL3Oz2Yi+Uc1IKlEHYkWEfqATtVp/cAdaFcqeDy9nkI2Iw
Cu/oCrjlZpRTG1jYfU2Y4ooRxBrKeiz7CV5hou8ZfAKEOQvcjIjBFhsctEXuAdVCoVbD
H3z13EAWQmt6AulsYV8qKDJrNi5uKiv6Y5U2gneR1ZBzRATrsPS1KNt+EDk3zVy93wlr
wj6g==
X-Gm-Message-State: AOAM533tT587Mwuo+Xy7l/v/lSFSYj9aaDm37NADmldWIRBlcwoQUlBM
vF2GFmZsauLg/XdYORAsml7efYHIE/jIA1H3/fSw+d4I9tc=
X-Google-Smtp-Source: ABdhPJxEQF0JS/2v74rtFtW3wzq/8mb9QK7bNZ6h7pcuk3DQv5UWQf7CfNLVje2PW87wGednFf5Xqcpxek1UdP6c8T8=
X-Received: by 2002:a2e:a40b:: with SMTP id p11mr17032020ljn.315.1608967391660;
Fri, 25 Dec 2020 23:23:11 -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: <477c1bbb-4647-81fe-595b-d54d0d9e00f4-at-ice-sa.com>
From: Sandhya
Date: Sat, 26 Dec 2020 12:52:59 +0530
Message-ID:
To: 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="===============0813923203=="
Errors-To: hangout-bounces-at-nylxs.com
Sender: "Hangout"

--===============0813923203==
Content-Type: multipart/alternative; boundary="000000000000d5cf5c05b758e960"

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

unsubscribe.

On Fri, Dec 25, 2020 at 10:30 PM Andr=C3=A9 Warnier (tomcat/perl) a.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 advocac=
y
> 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_perl=
.
> 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 kind
> 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 additional
> 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 of
> 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, y=
es 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, alon=
g
> 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 ne=
w
> 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 a=
t 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=
. 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 dat=
a for it =E2=80=93 and
> that is half the
> > sequenced samples in the whole world. The UK is sequencing more COVID-1=
9
> genomes a day
> > than most other countries have sequenced since the start of the pandemi=
c
> 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 cou=
ntry 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) are
> different in
> > different tissues;
> > * sequencing the genomes of other animals to understand their evolution=
;
> > * and looking at some other species in detail, to see what we can learn
> 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 to=
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 han=
dle is
> going up faster than
> > Moore=E2=80=99s Law! Many of us have pride in doing things as efficient=
ly as
> possible.
> >
> > It took around 10 years to sequence and assemble the first human genome
> {well we are still
> > tinkering with it and filling in the gaps} =E2=80=93 now at the institu=
te we can
> sequence and
> > assemble around 400 human genomes in a day =E2=80=93 to the same qualit=
y!
> >
> > 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 12=
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 to=
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 doing
> 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 redevelope=
d as the
> scale of the data
> > has got so big that even the summary pages we produced 10 years ago hav=
e
> 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 memory
> 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 sma=
ll
> cluster of machines!
> >
> > Our boxes are larger than that =E2=80=93 but they all run virtual m=
achine
> {only a small
> > proportion web related} =E2=80=93 machines/memory would rapidly bec=
ome 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 t=
o
> 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 additiona=
l
> constraints on
> > storage having the extra machines may have (at the last count a yea=
r
> ago we had over
> > 30 PBytes of storage on side =E2=80=93 and a large amount of offsit=
e 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 mov=
ing to
> the cloud is an
> > option we are looking at =E2=80=93 but that is more than 4 times th=
e 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 o=
f 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 being=
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, sequenc=
e 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 i=
t is just
> that we know we
> > have because of the amount of sequencing and analysis that we in th=
e
> 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 i=
n
> 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 th=
e
> only safe way to
> > do it is to use the Apache httpd prefork model. This means that
> 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 counted
> 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 abl=
e
> 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 can
> 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 processes
> 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 2
> > [google.com]
> > <
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_map=
s_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-2=
6source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3D=
oH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=3D=
xU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&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 2 [google.com]
> > <
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_map=
s_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-2=
6source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3D=
oH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=3D=
xU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&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.
> >
> > -- 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.
>
>

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

unsubscribe.

=3D"ltr" class=3D"gmail_attr">On Fri, Dec 25, 2020 at 10:30 PM Andr=C3=A9 W=
arnier (tomcat/perl) <aw-at-ice-sa.com=
> wrote:
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hell=
o 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 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 215 Euston Road, Lon=
don, NW1 2 [nk">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 215 Eust=
on 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 215 Euston Road, London, NW1 2BE.<=
br>




--000000000000d5cf5c05b758e960--

--===============0813923203==
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

--===============0813923203==--

--===============0813923203==
Content-Type: multipart/alternative; boundary="000000000000d5cf5c05b758e960"

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

unsubscribe.

On Fri, Dec 25, 2020 at 10:30 PM Andr=C3=A9 Warnier (tomcat/perl) a.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 advocac=
y
> 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_perl=
.
> 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 kind
> 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 additional
> 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 of
> 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, y=
es 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, alon=
g
> 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 ne=
w
> 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 a=
t 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=
. 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 dat=
a for it =E2=80=93 and
> that is half the
> > sequenced samples in the whole world. The UK is sequencing more COVID-1=
9
> genomes a day
> > than most other countries have sequenced since the start of the pandemi=
c
> 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 cou=
ntry 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) are
> different in
> > different tissues;
> > * sequencing the genomes of other animals to understand their evolution=
;
> > * and looking at some other species in detail, to see what we can learn
> 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 to=
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 han=
dle is
> going up faster than
> > Moore=E2=80=99s Law! Many of us have pride in doing things as efficient=
ly as
> possible.
> >
> > It took around 10 years to sequence and assemble the first human genome
> {well we are still
> > tinkering with it and filling in the gaps} =E2=80=93 now at the institu=
te we can
> sequence and
> > assemble around 400 human genomes in a day =E2=80=93 to the same qualit=
y!
> >
> > 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 12=
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 to=
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 doing
> 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 redevelope=
d as the
> scale of the data
> > has got so big that even the summary pages we produced 10 years ago hav=
e
> 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 memory
> 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 sma=
ll
> cluster of machines!
> >
> > Our boxes are larger than that =E2=80=93 but they all run virtual m=
achine
> {only a small
> > proportion web related} =E2=80=93 machines/memory would rapidly bec=
ome 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 t=
o
> 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 additiona=
l
> constraints on
> > storage having the extra machines may have (at the last count a yea=
r
> ago we had over
> > 30 PBytes of storage on side =E2=80=93 and a large amount of offsit=
e 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 mov=
ing to
> the cloud is an
> > option we are looking at =E2=80=93 but that is more than 4 times th=
e 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 o=
f 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 being=
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, sequenc=
e 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 i=
t is just
> that we know we
> > have because of the amount of sequencing and analysis that we in th=
e
> 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 i=
n
> 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 th=
e
> only safe way to
> > do it is to use the Apache httpd prefork model. This means that
> 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 counted
> 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 abl=
e
> 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 can
> 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 processes
> 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 2
> > [google.com]
> > <
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_map=
s_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-2=
6source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3D=
oH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=3D=
xU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&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 2 [google.com]
> > <
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.google.com_map=
s_search_s-2B215-2BEuston-2BRoad-2C-2BLondon-2C-2BNW1-2B2-3Fentry-3Dgmail-2=
6source-3Dg&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3D=
oH2yp0ge1ecj4oDX0XM7vQ&m=3DfriR8ykiZ-NWYdX6SrbT_ogNXEVR-4ixdkrhy5khQjA&s=3D=
xU3F4xE2ugQuDWHZ4GtDn9mPBCKcJJOI0PYScsSNjSg&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.
> >
> > -- 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.
>
>

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

unsubscribe.

=3D"ltr" class=3D"gmail_attr">On Fri, Dec 25, 2020 at 10:30 PM Andr=C3=A9 W=
arnier (tomcat/perl) <aw-at-ice-sa.com=
> wrote:
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hell=
o 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 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 215 Euston Road, Lon=
don, NW1 2 [nk">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 215 Eust=
on 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 215 Euston Road, London, NW1 2BE.<=
br>




--000000000000d5cf5c05b758e960--

--===============0813923203==
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

--===============0813923203==--

  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!