From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 31604c60 for ; Wed, 26 Jun 2019 19:25:55 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 8C9949BF75; Thu, 27 Jun 2019 05:25:54 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 53EBB9BD84; Thu, 27 Jun 2019 05:25:38 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="T3ONin9U"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9962F9BD84; Thu, 27 Jun 2019 05:25:36 +1000 (AEST) Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by minnie.tuhs.org (Postfix) with ESMTPS id B788C9BC77 for ; Thu, 27 Jun 2019 05:25:35 +1000 (AEST) Received: by mail-ot1-f68.google.com with SMTP id l15so3699362otn.9 for ; Wed, 26 Jun 2019 12:25:35 -0700 (PDT) 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=j2UvE97wXgOzr0XlSoCpe/AXjjsN7BPW2Rd4mYVwmdk=; b=T3ONin9UwkbUT045OD3SSwocLoLwYM8czqTY4qnldYzvKEvyzkOnNQRw41ZJNfooaL KVHUuyhLwOYtFsir4dVOG3F9VF5HSSqkupuw2D39vBKhqrc4rk2iSGrZ8bkkJqYoV1O9 gmoAMNS95oFXHFMxMN0OeByx/TNJDCactVKrko3MWsM4+kkcn9+m7mwfx4CZq5oN3q4W bGokO0ZwTriR+A9QhMpuQ1LZQLFxlFVRPQQdecYEXpBgDdzYfmui9uSVZe4qZr3DXCQJ SEu+jAb3Mi2bw8e1PAwHQ4XulT+KdN40ijvoCP6l3OwVyVjBvnPOjgwp4ELL92yb6AAF s1tA== 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=j2UvE97wXgOzr0XlSoCpe/AXjjsN7BPW2Rd4mYVwmdk=; b=Z+YhjicM5buV4c9Yxi7y71SIRXR1HYtkhCxJlr7ZMCUw3Ysldm9yyhKGvOrxH8eW0B TxNwQaKqpAJflDmBplDCb5uAIyYiaUTrG8GeSZijvp0GV5MnmpxsYuFDe7X5G4fdvDVN A+NN6awXd9ipOhOrsHTOoDW1YG5o7R4G4zR7vt+FpzTx5Jv0DClZM7X7xhmXic/wuP1Z Uj5CrtLZ9KseVDGoZm5sFfhTFHQ/NYCyC4EhbqmeajGe3+YZHcppiNDRasIghEF+GJ2j JssUs5o7f11hU6Q2NYaYdo3QcwmLlUtm0WpHWMXFcNh1YG4FC8uTwVYdjeWJ02XP1Tve tr8w== X-Gm-Message-State: APjAAAUKy0mX1b8eADHPw+uPCixpdeGlnioLiWE4X8M53bGIESijs/Mc jqaOwAFVkDtxte4jmbka7Ts/zB1YvBOyy+W1Pg4= X-Google-Smtp-Source: APXvYqytiE7tvIWuS8weII+eCu/e4erfd3ex9jLuEUvxuBM/Ukzb5XgfKPznWMvzL35AHS7TBeB7JGJUExkyMz4UrlU= X-Received: by 2002:a9d:3db7:: with SMTP id l52mr4491007otc.57.1561577134721; Wed, 26 Jun 2019 12:25:34 -0700 (PDT) MIME-Version: 1.0 References: <8D0B5B0D-9956-47D7-8D36-1729BB1E1DA9@eschatologist.net> <5df8c6f6-2768-4bfb-9c47-3345098078a7@PU1APC01FT048.eop-APC01.prod.protection.outlook.com> <20190625000630.GA7655@mcvoy.com> <20190625003120.GA28608@mit.edu> <20190625004523.GB7655@mcvoy.com> <20190626024503.GA43970@wopr> <20190626025646.GR925@mcvoy.com> <20190626151143.GC3116@mit.edu> In-Reply-To: <20190626151143.GC3116@mit.edu> From: Adam Thornton Date: Wed, 26 Jun 2019 12:25:23 -0700 Message-ID: To: "Theodore Ts'o" , tuhs@minnie.tuhs.org Content-Type: multipart/alternative; boundary="000000000000678e23058c3f028b" Subject: Re: [TUHS] CMU Mach sources? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000678e23058c3f028b Content-Type: text/plain; charset="UTF-8" "And the key for all of this is motivation and incentives, as any good historian will tell you. This is true whether probing the start of wars, or the decline of a technical community or tradition." This. I work for the Large Synoptic Survey Telescope. I'm in the Data Management group, and specifically in the Science Quality and Reliability Engineering team. The 50,000 foot view of what we do is try to bring software engineering to astronomical software. In general, the thing about scientific software is that, to put it crudely, no one gets a Nobel Prize for software. There's a very strong incentive to write a thing that will solve whatever particular problem you need solved for your paper, and no more. There's also the (highly correlated) problem that, to an established researcher, graduate student labor is free, and your graduate students want to finish their thesis, not engineer quality software. Whereas what I'd like to do is factor the common infrastructure--of which there is a lot--out of the various teetering stacks of special-purpose software and create some sane and maintainable infrastructure that individual researchers can easily and relatively gracefully extend to answer their specific questions. Adam On Wed, Jun 26, 2019 at 8:12 AM Theodore Ts'o wrote: > On Tue, Jun 25, 2019 at 07:56:46PM -0700, Larry McVoy wrote: > > > It might not be, but it is definitely relevant to Unix. Arguably the > > > drivers of Unix's development movement away from R&D-focused places and > > > toward product-oriented entities had at least a little to do with > > > Larry's topic of complaint. Product managers gained the ammunition to > > > demand sustainable development practices, while R&D got a little > leaner, > > > a little more focused on demonstrating the thesis, a little less > focused > > > on who might need to run this code five years on... > > > > In the good old days at Sun, we were very focussed on who would run > > this code for decades to come. I think the engineers at Sun were very > > focussed on helping people, the reason we were there was because the > > work we did helped people. The leverage was how much work we could > > do versus how much that helped people. That is product oriented. > > > > I think the reason that any engineer works is because they feel like > > their work helps someone. As an engineer, I wanted to go to the place > > and do the work that had the best chance of helping someone. All of > > Sun, when I was there, was like that. We were there to help. Yeah, > > of course, we wanted to make money, but all of us wanted to help. > > It's the dream, you do work, your work helps. > > Motivations and incentives are a very big and important aspect which > is often overlooked in large scale projects. > > For example, one of the really big problems with device drivers in the > embedded space is that the team that works on SOC version X gets > disbanded, and immediately reassigned to SOC verison X+1, sometimes > before product has even shipped. Having one device driver that works > for SOC versions N, N+1, N+2, ... N+5, is really important from a > maintainability and being able to send out bug fixes for security > flaws. However, it means that whenever you make changes, you need to > test on N different older versions. And between the need to release > product quickly, and the fact that engineers are !@#@! expensive, and > the teams constantly getting formed and reformed, it's much easier to > do code reuse by copying, and so you have N different versions of a > device driver in a Board Support Package version of the Linux kernel > shipping by a SOC vendor. > > Unfortunately, I have to disagree with Larry, there are many, many > engineers who works because they get a paycheck, and so they go home > at 5pm. Some people might be free to improve their code on their own > time, or late at night, but corporation also preach "work/life > balance" --- and then don't fund time for making code long-term > maintainable or reducing tech debt. > > Open source helps because embarassment can be a great motivator, but > more important are the fact that there are people who are empowered to > say "no" who don't work for the corporation who is trying to cut > corners, and who have a higher allegiance to the codebase than their > employer. > > There is a similar related issue around publishing papers to document > great ideas. This takes time away from product development, and it > used to be that Sun was really prolific at documenting their technical > innovations at conferences like Usenix. Over time, the academic > traditions started dying off, and managers who came from that > tradition moved on, retired, or got promoted beyond the point where > they could encourage engineers to do that work. And it wasn't just at > Sun; I was working at IBM when IBM decided to take away the (de > minimus) bonus for publishing papers at conferences. But at the > Usenix board, I remember looking at a chart of the declining number of > ATC papers coming from industry over time. And it was very depressing... > > And the key for all of this is motivation and incentives, as any good > historian will tell you. This is true whether probing the start of > wars, or the decline of a technical community or tradition. > > - Ted > --000000000000678e23058c3f028b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"And the key for all of this is motivation and incent= ives, as any good
historian will tell you.=C2=A0 This is true whether pr= obing the start of
wars, or the decline of a technical community or trad= ition."

This.

I work for the Large Synoptic = Survey Telescope.=C2=A0 I'm in the Data Management group, and specifica= lly in the Science Quality and Reliability Engineering team.=C2=A0 The 50,0= 00 foot view of what we do is try to bring software engineering to astronom= ical software.

In general, the thing about scienti= fic software is that, to put it crudely, no one gets a Nobel Prize for soft= ware.=C2=A0 There's a very strong incentive to write a thing that will = solve whatever particular problem you need solved for your paper, and no mo= re.=C2=A0 There's also the (highly correlated) problem that, to an esta= blished researcher, graduate student labor is free, and your graduate stude= nts want to finish their thesis, not engineer quality software.
<= br>
Whereas what I'd like to do is factor the common infrastr= ucture--of which there is a lot--out of the various teetering stacks of spe= cial-purpose software and create some sane and maintainable infrastructure = that individual researchers can easily and relatively gracefully extend to = answer their specific questions.

Adam
<= br>
On Wed,= Jun 26, 2019 at 8:12 AM Theodore Ts'o <tytso@mit.edu> wrote:
On Tue, Jun 25, 2019 at 07:56:46PM -0700, Larry McVoy wro= te:
> > It might not be, but it is definitely relevant to Unix.=C2=A0 Arg= uably the
> > drivers of Unix's development movement away from R&D-focu= sed places and
> > toward product-oriented entities had at least a little to do with=
> > Larry's topic of complaint.=C2=A0 Product managers gained the= ammunition to
> > demand sustainable development practices, while R&D got a lit= tle leaner,
> > a little more focused on demonstrating the thesis, a little less = focused
> > on who might need to run this code five years on...
>
> In the good old days at Sun, we were very focussed on who would run > this code for decades to come.=C2=A0 I think the engineers at Sun were= very
> focussed on helping people, the reason we were there was because the > work we did helped people.=C2=A0 The leverage was how much work we cou= ld
> do versus how much that helped people.=C2=A0 That is product oriented.=
>
> I think the reason that any engineer works is because they feel like > their work helps someone.=C2=A0 As an engineer, I wanted to go to the = place
> and do the work that had the best chance of helping someone.=C2=A0 All= of
> Sun, when I was there, was like that.=C2=A0 We were there to help.=C2= =A0 Yeah,
> of course, we wanted to make money, but all of us wanted to help.
> It's the dream, you do work, your work helps.

Motivations and incentives are a very big and important aspect which
is often overlooked in large scale projects.

For example, one of the really big problems with device drivers in the
embedded space is that the team that works on SOC version X gets
disbanded, and immediately reassigned to SOC verison X+1, sometimes
before product has even shipped.=C2=A0 Having one device driver that works<= br> for SOC versions N, N+1, N+2, ... N+5, is really important from a
maintainability and being able to send out bug fixes for security
flaws.=C2=A0 However, it means that whenever you make changes, you need to<= br> test on N different older versions.=C2=A0 And between the need to release product quickly, and the fact that engineers are !@#@! expensive, and
the teams constantly getting formed and reformed, it's much easier to do code reuse by copying, and so you have N different versions of a
device driver in a Board Support Package version of the Linux kernel
shipping by a SOC vendor.

Unfortunately, I have to disagree with Larry, there are many, many
engineers who works because they get a paycheck, and so they go home
at 5pm.=C2=A0 Some people might be free to improve their code on their own<= br> time, or late at night, but corporation also preach "work/life
balance" --- and then don't fund time for making code long-term maintainable or reducing tech debt.

Open source helps because embarassment can be a great motivator, but
more important are the fact that there are people who are empowered to
say "no" who don't work for the corporation who is trying to = cut
corners, and who have a higher allegiance to the codebase than their
employer.

There is a similar related issue around publishing papers to document
great ideas.=C2=A0 This takes time away from product development, and it used to be that Sun was really prolific at documenting their technical
innovations at conferences like Usenix.=C2=A0 Over time, the academic
traditions started dying off, and managers who came from that
tradition moved on, retired, or got promoted beyond the point where
they could encourage engineers to do that work.=C2=A0 And it wasn't jus= t at
Sun; I was working at IBM when IBM decided to take away the (de
minimus) bonus for publishing papers at conferences.=C2=A0 But at the
Usenix board, I remember looking at a chart of the declining number of
ATC papers coming from industry over time.=C2=A0 =C2=A0And it was very depr= essing...

And the key for all of this is motivation and incentives, as any good
historian will tell you.=C2=A0 This is true whether probing the start of wars, or the decline of a technical community or tradition.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0- Ted
--000000000000678e23058c3f028b--