From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id B76DA22F5B for ; Wed, 19 Jun 2024 23:29:29 +0200 (CEST) Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed Jun 19 17:28:43 -0400 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1718832491; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iY+sg66hELX1ODROen3eMneHEuB7MToiX7Hrx3+1OdQ=; b=dt+JUzwBmKoDUTl34Mnq3nqP/WOF7a5td5scwBX9pLffUX65TeyUBqqBG2QtDD5mALpZbV 7U9SwHTP54hgW7inUesyNXR8Wmu9RfVZITrjzLHREOuJxdoiVgl5P/kzGa+odPqnb/Zqh/ KzAwAzZiMIkk6g3c7IIz1aqmFucAlg4= Received: from [192.168.168.200] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id e785f242 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Wed, 19 Jun 2024 16:28:11 -0500 (CDT) Message-ID: <8124838e-a6a3-41ea-9169-5a5fe42347fc@posixcafe.org> Date: Wed, 19 Jun 2024 16:28:42 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: Content-Language: en-US From: Jacob Moody In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: hosting service layer Subject: Re: [9front] ndb doc patch Reply-To: 9front@9front.org Precedence: bulk On 6/18/24 12:35, Romano wrote: > Hello list, > > At the end of last year I had a small patch > for ndb's man page. There was a bit of > discussion re: it in January ( https://inbox.vuxu.org/9front/39A39E500516DB6E2B4CE0BC27677DEF@eigenstate.org/ ) > and I have tried to address Ori's suggestion > here: http://okturing.com/src/20100/body I would probably much prefer to fix this than to document a bug. If anything should change regarding this, it should be picking a sensible maximum and then documenting it in ndb(6) as part of the file specification. Not in ndb(8) as a bug of the implementation. Thanks, moody