"professional conferences and scientific education" typically employ a quite vigorous process to vet their speakers. This has clearly not happened here ...
Regarding "Who do you think you're talking to": this has basically devolved into a pointless dialog between the two of us, since there is all but thundering silence from the actual devs here. On Mon, 2023-09-25 at 21:59 +0000, Eponymous Pseudonym wrote: > Every one, Every where, All ways, You too. That's what professional > conferences and scientific education is for. Who do you think you're > talking to, the mailing list archive readers of a social club for > knitting for the elderly? That is correct too. Time will and does > demonstrate it perfectly. > > On 9/25/23, Rudolf Leitgeb <rudolf.leit...@gmx.at> wrote: > > Are you trying to teach the OpenBSD devs how to write good > > software? > > > > Unix software? > > > > Really? > > > > REALLY ????? > > > > On Mon, 2023-09-25 at 21:11 +0000, Eponymous Pseudonym wrote: > > > Standardisation, specification and documentation as a starting > > > point > > > for software creation is a normal, reliable and mandated > > > (formally) > > > methodology used everywhere from business to scientific, > > > industrial, > > > medical and military applications. It is not only normal but > > > expected > > > and even required that amateur free and open software follow the > > > same > > > processes and procedures as professional modelling and > > > implementation, > > > especially on historically significant long term projects that > > > are > > > also programming languages and interpreters. > > > > > > It's not a surprise to you, everything in UNIX is a compiler > > > construction reuse tooling and a small (and large) domain > > > specific > > > languages. That is the essence of the system. OpenBSD is a > > > descendant of UNIX, not a free walk in the green pastures of > > > experimental shareware. Now, let's get back to more productive > > > time > > > and space utilisation, kids, good ideas.. third party re-imports > > > are > > > waiting their normalisation and stabilisation to robust and > > > reliable > > > distillations of core "base and extended" system modular > > > componentry. > > > Re-read the long version of the previous post after some > > > specialised > > > references again, and you will see and understand what I outlined > > > clearly. > > > > > https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text > https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History > https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles > > > > > > > Thanks for the discussion and support, I've said my points and > > > think > > > we're in accord and agreement on all details referenced. > > > > > > On 9/25/23, Rudolf Leitgeb <rudolf.leit...@gmx.at> wrote: > > > > If you document a switch, you are basically required to keep > > > > that > > > > functionality around forever. Given that the OpenBSD devs don't > > > > like > > > > these --options all that much, I don't see that happening. > > > > Submitting > > > > a patch won't change that. > > > > > > > > IMHO there's nothing wrong, if software can do more than its > > > > documentation shows. It's not like it breaks documented > > > > behavior. > > > > > > > > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote: > > > > > Don't rant that long. > > > > > > > > > > Sometimes, documentation and code get out-of-synch for a lot > > > > > of > > > > > reasons. > > > > > > > > > > - trying out stuff and documenting later. > > > > > - plain forgetting to update the documentation. > > > > > - having some stuff for a transition period, and then killing > > > > > it. > > > > > > > > > > Your point that stuff that stays around, should ideally be > > > > > documented, > > > > > is a good point. > > > > > > > > > > Now, you gotta realize that people have limited time to do > > > > > everything. > > > > > > > > > > In general, patches are welcome. > > > > > > > > > > In my long tenure on various tools, I've learnt that > > > > > documenting > > > > > stuff is always always a good idea: if you get a new feature > > > > > BUT > > > > > you can't explain it cleanly, then you should go back to the > > > > > drawing-board !
