From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp114.iad3a.emailsrvr.com (smtp114.iad3a.emailsrvr.com [173.203.187.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3385D3B29D for ; Tue, 30 Mar 2021 21:23:51 -0400 (EDT) Received: from app24.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp15.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AFD51426B; Tue, 30 Mar 2021 21:23:50 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app24.wa-webapps.iad3a (Postfix) with ESMTP id 99099E0064; Tue, 30 Mar 2021 21:23:50 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 30 Mar 2021 21:23:50 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 30 Mar 2021 21:23:50 -0400 (EDT) From: "David P. Reed" To: "Theodore Ts'o" Cc: "Dave Taht" , "Cake List" , "Make-Wifi-fast" , "Jason A. Donenfeld" , "cerowrt-devel" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20210330212350000000_87018" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1617049691.187521510@apps.rackspace.com> X-Client-IP: 209.6.168.128 Message-ID: <1617153830.6256867@apps.rackspace.com> X-Mailer: webmail/18.1.24-RC X-Classification-ID: 9929edfa-e77d-46a5-8d19-71cd620799c3-1-1 Subject: Re: [Make-wifi-fast] [Cerowrt-devel] wireguard almost takes a bullet X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 01:23:51 -0000 ------=_20210330212350000000_87018 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ATheodore -=0A =0AI appreciate you showing the LF executive salary number= s are not quite as high as I noted. My numbers may have been inflated, but = I've definitely seen a $900,000 package for at least one executive reported= in the press (an executive who was transferred in from a F100 company whic= h is close to the LF).=0A =0AOn the other hand, they are pretty damn high s= alaries for a non-profit. Are they appropriate? Depends. There are no stock= holders and no profits, just a pretty substantial net worth.=0A =0ARegardin= g the organizaton of "Linux, Inc." as a hierachical control structure - I'= ll just point out that hierarchical control of the development of Linux sug= gests that it is not at all a "community project" (if it ever was). It's a = product development organization with multiple levels of management.=0A =0A= Yet the developers are employees of a small number of major corporations. I= n this sense, it is like a "joint venture" among those companies.=0A =0ATo = the extent that those companies gain (partial) control of the Linux kernel,= as appears to be the case, I think Linux misrepresents itself as a "commun= ity project", and in particular, the actual users of the software may have = little say in the direction development takes going forwards.=0A =0AThere's= little safeguard, for example, against "senior management" biases in suppo= rt of certain vendors, if other vendors are excluded from effective partici= pation by one of many techniques. In other words, there's no way it can be = a level playing field for innovation.=0A =0AIn that sense, the Linux kernel= community has reached a point very much like Microsoft Windows development= reached in 1990 or so. I note that date because at that point, Microsoft w= as challenged with a variety of anti-trust actions based on the fact that i= t used its Windows monopoly status to put competitors in the application sp= ace, and competitors producing innovative operating systems out of business= (GO Computer Corporation being one example of many).=0A =0AThis troubles m= e. It may not trouble the developers who are in the Linux community and pai= d by the cartel of companies that control its direction.=0A =0AI have no co= mplaint about the technical competence of individual developers - the quali= ty is pretty high, at least as good as those who worked on Windows and macO= S. But it's becoming clear that their is a narrowing of control of an OS th= at has a lot of influence in a few hands. That those few hands don't work f= or one company doesn't eliminate its tendency to become a cartel. (one that= is not transparent at all about functioning as such - preferring to give t= he impression that the kernel is developed by part-time voluntary "contribu= tions").=0A =0AThe contrast with other open source communities is quite sha= rp now. There is little eleemosynary intent that can be detected any more. = I think that is too bad, but things change.=0A =0AThis is just the personal= opinion of someone who has been developing systems for 50+ years now. I'm = kind of disappointed, but my opinion does not really matter much.=0A =0ADav= id=0A =0A =0A =0A =0AOn Monday, March 29, 2021 9:52pm, "Theodore Ts'o" said:=0A=0A=0A=0A> On Mon, Mar 29, 2021 at 04:28:11PM -0400, Da= vid P. Reed wrote:=0A> >=0A> >=0A> > What tends to shape Linux and FreeBSD,= etc. are the money sources=0A> > that flow into the communities. Of course= Linux is quite=0A> > independently wealthy now. The senior executives of t= he Linux=0A> > Foundation are paid nearly a million dollars a year, each. W= hich=0A> > just indicates that major corporations are seriously interested = in=0A> > controlling the evolution of Linux (not the Gnu part, the part tha= t=0A> > has Linus Torvalds at its center).=0A> =0A> First of all, I don't b= elieve your salary numbers are correct.=0A> =0A> https://nonprofitlight.com= /ca/san-francisco/linux-foundation=0A> =0A> Secondly, the "senior executive= s" of the Linux Foundation don't have=0A> any control over "the evolution o= f Linux". The exception to that are=0A> the "Fellows" (e.g., Linus Torvalds= , Greg K-H, etc.) and I can assure=0A> you that they don't take orders from= Jim Zemlin, the executive=0A> director, or any one else at the Linux Found= ation.=0A> =0A> The senior developers of Linux do tend to work for the big= =0A> corporations, but culturally, we do try to keep our "corporate hats"= =0A> and our "community" hats quite separate, and identify when we our=0A> = company hats on. Many senior developers have transitioned between=0A> multi= ple companies, and over time, it's been understood that their=0A> primarily= allegiance is to Linux, and not to the company. In fact,=0A> the primary j= ob of maintainers is to say "no" to companies when they=0A> try to push cra= p code into the kernel. And that's because it's the=0A> maintainer's respon= sibility to clean up the mess if they say yes to=0A> code that's Just Not R= eady, since they have a long-term responsbility=0A> towards their subsystem= , unlike engineers or contractors that only=0A> have a short-term goal to g= et the code upstream.=0A> =0A> This is where having a hierarchial ownership= model IMHO works better=0A> than a "core team" model where there can be a = diffusion of=0A> responsibility, where anyone with a commit bit can commit = anywhere in=0A> the OS. In contrast, David Miller "owns" the networking are= a, and so=0A> someone who might be, say, the ext4 or xfs maintainer does no= t have=0A> the right (read: Linus will reject a pull request from me if I t= ry to=0A> change code in the networking stack with out DaveM's signoff) to= =0A> change code outside of their subsystem.=0A> =0A> So you're right that = Linus probably doesn't know or care about=0A> bufferbloat. He's delegated p= retty much all networking issues to=0A> David Miller as the networking czar= , and within networking, David=0A> Miller has his submaintainers with diffe= rent specialities. This does=0A> get complicated when there are changes whi= ch cross subsystems. For=0A> example, before Wireguard could land in the ke= rnel, there were changes=0A> needed in both the crypto and networking layer= s, and Jason had to=0A> negotiate with multiple senior developers in those = subsystems, and the=0A> code was subject to quite a lot of review before it= could land. (It=0A> took months, and we didn't try to rush things before a= major=0A> release....)=0A> =0A> > I just spent 9 months trying to get a ve= ry tiny fix to the Linux=0A> > kernel into the mainline kernel. I actually = gave up, because it=0A> > seemed utterly pointless, even though it was clea= rly a design error=0A> > that I was fixing, and I was trying to meet all th= e constraints on=0A> > patches. No one was fighting me, no one said it was = wrong.=0A> =0A> It sounds like the real problem is no one was paying attent= ion to you.=0A> There is a *huge* number of changes going into the Linux ke= rnel, and=0A> so the the challenge is getting review bandwidth by the relev= ant=0A> maintainers. Blindly posting to the linux-kernel mailing list will= =0A> generally not get you very far.=0A> =0A> The Linux development process= is not really optimized for "drive by=0A> patching". Knowng where (and to = whom) a patch needs to be reviewed is=0A> not necessarily easy for a novice= , and while there are tools such as=0A> ./scripts/get_maintainer.pl that tr= y to make it a bit easier, I can=0A> see how someone who Just Wants To Get = A Single Patch accepted, can see=0A> it as "bureaucracy".=0A> =0A> Cheers,= =0A> =0A> - Ted=0A> ------=_20210330212350000000_87018 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Theodore -

=0A

 

=0A

I appreciate you showing = the LF executive salary numbers are not quite as high as I noted. My number= s may have been inflated, but I've definitely seen a $900,000 package for a= t least one executive reported in the press (an executive who was transferr= ed in from a F100 company which is close to the LF).

=0A

 

=0A

On the other hand, they are pretty d= amn high salaries for a non-profit. Are they appropriate? Depends. There ar= e no stockholders and no profits, just a pretty substantial net worth.

= =0A

 

=0A

Regarding the org= anizaton of "Linux, Inc." as  a hierachical control structure - I'll j= ust point out that hierarchical control of the development of Linux suggest= s that it is not at all a "community project" (if it ever was). It's a prod= uct development organization with multiple levels of management.

=0A

 

=0A

Yet the developers are e= mployees of a small number of major corporations. In this sense, it is like= a "joint venture" among those companies.

=0A

 =

=0A

To the extent that those companies gain (partia= l) control of the Linux kernel, as appears to be the case, I think Linux mi= srepresents itself as a "community project", and in particular, the actual = users of the software may have little say in the direction development take= s going forwards.

=0A

 

=0A

There's little safeguard, for example, against "senior management" bias= es in support of certain vendors, if other vendors are excluded from effect= ive participation by one of many techniques. In other words, there's no way= it can be a level playing field for innovation.

=0A

 

=0A

In that sense, the Linux kernel communit= y has reached a point very much like Microsoft Windows development reached = in 1990 or so. I note that date because at that point, Microsoft was challe= nged with a variety of anti-trust actions based on the fact that it used it= s Windows monopoly status to put competitors in the application space, and = competitors producing innovative operating systems out of business (GO Comp= uter Corporation being one example of many).

=0A

&nb= sp;

=0A

This troubles me. It may not trouble the dev= elopers who are in the Linux community and paid by the cartel of companies = that control its direction.

=0A

 

=0A

I have no complaint about the technical competence of individ= ual developers - the quality is pretty high, at least as good as those who = worked on Windows and macOS. But it's becoming clear that their is a narrow= ing of control of an OS that has a lot of influence in a few hands. That th= ose few hands don't work for one company doesn't eliminate its tendency to = become a cartel. (one that is not transparent at all about functioning as s= uch - preferring to give the impression that the kernel is developed by par= t-time voluntary "contributions").

=0A

 

=0A=

The contrast with other open source communities is qui= te sharp now. There is little eleemosynary intent that can be detected= any more. I think that is too bad, but things change.

=0A

 

=0A

This is just the personal opinion = of someone who has been developing systems for 50+ years now. I'm kind of d= isappointed, but my opinion does not really matter much.

=0A

 

=0A

David

=0A

 

=0A

 

=0A

 =

=0A

 

=0A

On Monday, Ma= rch 29, 2021 9:52pm, "Theodore Ts'o" <tytso@mit.edu> said:

=0A
=0A

> On Mo= n, Mar 29, 2021 at 04:28:11PM -0400, David P. Reed wrote:
> >> >
> > What tends to shape Linux and FreeBSD, etc. are= the money sources
> > that flow into the communities. Of course= Linux is quite
> > independently wealthy now. The senior execut= ives of the Linux
> > Foundation are paid nearly a million dolla= rs a year, each. Which
> > just indicates that major corporation= s are seriously interested in
> > controlling the evolution of L= inux (not the Gnu part, the part that
> > has Linus Torvalds at = its center).
>
> First of all, I don't believe your salary= numbers are correct.
>
> https://nonprofitlight.com/ca/sa= n-francisco/linux-foundation
>
> Secondly, the "senior exe= cutives" of the Linux Foundation don't have
> any control over "the= evolution of Linux". The exception to that are
> the "Fellows" (e.= g., Linus Torvalds, Greg K-H, etc.) and I can assure
> you that the= y don't take orders from Jim Zemlin, the executive
> director, or a= ny one else at the Linux Foundation.
>
> The senior develo= pers of Linux do tend to work for the big
> corporations, but cultu= rally, we do try to keep our "corporate hats"
> and our "community"= hats quite separate, and identify when we our
> company hats on. M= any senior developers have transitioned between
> multiple companie= s, and over time, it's been understood that their
> primarily alleg= iance is to Linux, and not to the company. In fact,
> the primary j= ob of maintainers is to say "no" to companies when they
> try to pu= sh crap code into the kernel. And that's because it's the
> maintai= ner's responsibility to clean up the mess if they say yes to
> code= that's Just Not Ready, since they have a long-term responsbility
>= towards their subsystem, unlike engineers or contractors that only
&g= t; have a short-term goal to get the code upstream.
>
> Th= is is where having a hierarchial ownership model IMHO works better
>= ; than a "core team" model where there can be a diffusion of
> resp= onsibility, where anyone with a commit bit can commit anywhere in
>= the OS. In contrast, David Miller "owns" the networking area, and so
= > someone who might be, say, the ext4 or xfs maintainer does not have> the right (read: Linus will reject a pull request from me if I try = to
> change code in the networking stack with out DaveM's signoff) = to
> change code outside of their subsystem.
>
> S= o you're right that Linus probably doesn't know or care about
> buf= ferbloat. He's delegated pretty much all networking issues to
> Dav= id Miller as the networking czar, and within networking, David
> Mi= ller has his submaintainers with different specialities. This does
>= ; get complicated when there are changes which cross subsystems. For
&= gt; example, before Wireguard could land in the kernel, there were changes<= br />> needed in both the crypto and networking layers, and Jason had to=
> negotiate with multiple senior developers in those subsystems, a= nd the
> code was subject to quite a lot of review before it could = land. (It
> took months, and we didn't try to rush things before a = major
> release....)
>
> > I just spent 9 month= s trying to get a very tiny fix to the Linux
> > kernel into the= mainline kernel. I actually gave up, because it
> > seemed utte= rly pointless, even though it was clearly a design error
> > tha= t I was fixing, and I was trying to meet all the constraints on
> &= gt; patches. No one was fighting me, no one said it was wrong.
> > It sounds like the real problem is no one was paying attention to = you.
> There is a *huge* number of changes going into the Linux ker= nel, and
> so the the challenge is getting review bandwidth by the = relevant
> maintainers. Blindly posting to the linux-kernel mailing= list will
> generally not get you very far.
>
> T= he Linux development process is not really optimized for "drive by
>= ; patching". Knowng where (and to whom) a patch needs to be reviewed is
> not necessarily easy for a novice, and while there are tools such as=
> ./scripts/get_maintainer.pl that try to make it a bit easier, I = can
> see how someone who Just Wants To Get A Single Patch accepted= , can see
> it as "bureaucracy".
>
> Cheers,
= >
> - Ted
>

=0A
 ------=_20210330212350000000_87018--