From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6658 invoked from network); 19 Jan 2023 17:00:15 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 19 Jan 2023 17:00:15 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 2FD434246B; Fri, 20 Jan 2023 03:00:08 +1000 (AEST) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 50B6F4246A for ; Fri, 20 Jan 2023 03:00:01 +1000 (AEST) Received: by mail-ed1-f52.google.com with SMTP id x36so3594981ede.13 for ; Thu, 19 Jan 2023 09:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=E5/00bll5SG5i7dz7D+LBtEUJX2xZbFGzyniBfhKGkA=; b=TpjEeC0MdwbEsUrp4CrDImM8RwwCmnQy7ts8IrWzQz9unR/spvurCKWToSCSIsehq3 pltI5kEXxx+Ih86ECExQWwb6lxqVhzk12jGNpPoB/5U0l4gFF7j443KCRD/iASIYWNOg 6srkoSsjXBQNQ8NOMNcMFHPuQKM2SVaCv1DaXr6BY0VIMRquKZjDDiGOTjZXl+eewGP/ S7rUQS5tZSvPK9j9wUbG0A1MsvvKkNh67NXRSDHIKjxXFgWqyWSKxNUOyKhMAliZf1u7 VbRTKvouXw0tK6wHmhInQbPvlkBmQ74WH0Bmvv+Ix0e1hmlsybglk/eBkYoh4BBAooWH guDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E5/00bll5SG5i7dz7D+LBtEUJX2xZbFGzyniBfhKGkA=; b=pozM69AU7c/faHg4+EDIwF6eN5A0lDHvJdWo0qHi4lua9FfG8brNfk7bV4UqAdG8LV dDHKjcCc2TEX8Dm8ok+LQnz9YpredOCdEQ3ButZ7it6L3XydQqgSXxgj57ZOCHOADNdn TRN7frWiF/Gg6HN9YYVnRzh61TK2i5WJxaf7XO9Fsscf4XO6XyW2fRa3l6y30cu8SpB5 WDK832cjtRzFDQUG58JN8AAzL0tzh5H6vFE0BOqxY2nhLlonN82LKzJfK0LfQAuIuT2g Hh40z9l5Je5wF9S3ctQPMoLR9OO+xMZVNC4bIzgW180a2dbmBmTmWEn4YlG4RgXfQ+W2 VIuQ== X-Gm-Message-State: AFqh2kovCboneuI3SdY06ibel0e6wnuTwkDEJDfS8r43R9XaUpGCV+a5 LcDj6/qw+WQ7KiRwe/kTw9OF+NRUH3t3sZZ1s5wtIQ== X-Google-Smtp-Source: AMrXdXsawGmya8RUE5DBC0QH1mUqRdmnXpSxu69qPzw2/xUuA9+e5aHlhgoXu3hRCCDvfXL14gz8k1pP4diKAP1oeCI= X-Received: by 2002:a05:6402:1008:b0:499:f0f:f788 with SMTP id c8-20020a056402100800b004990f0ff788mr1416204edu.25.1674147539713; Thu, 19 Jan 2023 08:58:59 -0800 (PST) MIME-Version: 1.0 References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> In-Reply-To: From: Warner Losh Date: Thu, 19 Jan 2023 09:58:48 -0700 Message-ID: To: Dan Cross Content-Type: multipart/alternative; boundary="000000000000680f1c05f2a0d90f" Message-ID-Hash: 2L6ZEE7YWEQ5SIW3MJAA2DBJOUGYFGIO X-Message-ID-Hash: 2L6ZEE7YWEQ5SIW3MJAA2DBJOUGYFGIO X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: AIX moved into maintainance mode List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000680f1c05f2a0d90f Content-Type: text/plain; charset="UTF-8" On Thu, Jan 19, 2023 at 9:41 AM Dan Cross wrote: > But it's interesting the way the "Gods of BSD vs the rebel alliance" > thing seems to have inverted itself. Getting stuff done in Linux these > days is pretty hard; oh sure, I suppose if you whip off a patch fixing > a typo in a comment or something, someone will just apply it. But if > you want to do something substantial, you have to be willing to invest > a lot of time and effort in shepherding it through the upstreaming > process, which implies you've got to have resources backing that > effort. And there's definitely an in-group. Meanwhile, the BSDs seem a > lot more accepting; maybe that's just me. At least FreeBSD and > DragonFly appear that way. Anyway, it seems fair to say that Linux > seems mostly beholden to the interests of big companies these days. > This matches my experience: Lots of gatekeepers, any one of which can take a disliking to your submission for what, at times, seems like arbitrary and capricious reasons. If you make it to the 'in crowd' it becomes more of a rubber stamp at times... I have recently been successful at submitting an obvious fix to a tiny backwater area of the kernel without undue stress though... But I submitted it to the maintainer of the area, who then submitted it to the 'greater maintainer', and then to the greater maintainer and then to the tree. So my tiny fix has more Signed-off-by: lines than lines of change and took about two weeks to make its way all the way up into the repo... For me, it took about 2x as long to prep and send the change than it does for the direct commit access I have for FreeBSD, but I've spent more than 10x on other submissions that ultimately didn't make it in. This is in contrast to the few changes I got in in the 90s: I sent an email to Ralf, who nit picked one or two things, which I fixed and it wound up in his next batch of changes to Linus and made its way in (to code that's sense been deleted, alas). The BSD are more accepting, in general, though it can be hard to find the right person to approve your change. There's too many ingest points still, too many things fall on the floor, etc. Part of that is tooling, part of it is culture, part of it is lack of clear docs, etc. It is generally easier to get a change into the BSDs. It takes less persistance, on the average, but it still takes more effort than it should. I looked into Linux's processes to improve FreeBSD's. And came to the conclusion that in large part they succeed despite their processes, not because of them. They have too much overhead, rely too much on magic bots that are hard to replicate and I'm astonished that things work as well as they do. It's a grown culture / process that relies on old tools mixed with new in weird ways you'd never think of standing up today. Things can be learned from it, but it seems to be a unique snowflake relative to all the other projects I looked at... Warner --000000000000680f1c05f2a0d90f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 19, 2023 at 9:41 AM Dan C= ross <crossd@gmail.com> wrote= :
But it's interesting the way the "Gods of BSD vs the rebel allianc= e"
thing seems to have inverted itself. Getting stuff done in Linux these
days is pretty hard; oh sure, I suppose if you whip off a patch fixing
a typo in a comment or something, someone will just apply it. But if
you want to do something substantial, you have to be willing to invest
a lot of time and effort in shepherding it through the upstreaming
process, which implies you've got to have resources backing that
effort. And there's definitely an in-group. Meanwhile, the BSDs seem a<= br> lot more accepting; maybe that's just me. At least FreeBSD and
DragonFly appear that way. Anyway, it seems fair to say that Linux
seems mostly beholden to the interests of big companies these days.

This matches my experience: Lots of gatekeeper= s, any one of which can take a disliking to your submission for what, at ti= mes, seems like arbitrary and capricious reasons. If you make it to the = 9;in crowd' it becomes more of a rubber stamp at times...=C2=A0 I have = recently been successful at submitting an obvious fix to a tiny backwater a= rea of the kernel without undue stress though...=C2=A0 But I submitted it t= o the maintainer of the area, who then submitted it to the 'greater mai= ntainer', and then to the greater maintainer and then to the tree. So m= y tiny fix has more Signed-off-by: lines than lines of change and took abou= t two weeks to make its way all the way up into the repo... For me, it took= about 2x as long to prep and send the change than it does for the direct c= ommit access I have for FreeBSD, but I've spent more than 10x on other = submissions that ultimately didn't make it in. This is in contrast to t= he few changes I got in in the 90s: I sent an email to Ralf, who nit picked= one or two things, which I fixed and it wound up in his next batch of chan= ges to Linus and made its way in (to code that's sense been deleted, al= as).

The BSD are more accepting, in general, thoug= h it can be hard to find the right person to approve your change. There'= ;s too many ingest points still, too many things fall on the floor, etc. Pa= rt of that is tooling, part of it is culture, part of it is lack of clear d= ocs, etc. It is generally easier to get a change into the BSDs. It takes le= ss persistance, on the average, but it still takes more effort than it shou= ld.

I looked into Linux's processes to improve= FreeBSD's. And came to the conclusion that in large part they succeed = despite their processes, not because of them. They have too much overhead, = rely too much on magic bots that are hard to replicate and I'm astonish= ed that things work as well as they do. It's a grown culture / process = that relies on old tools mixed with new in weird ways you'd never think= of standing up today. Things can be learned from it, but it seems to be a = unique snowflake relative to all the other projects I looked at...

Warner

--000000000000680f1c05f2a0d90f--