Well, let me introduce myself (again). I started personally with electronics and real computing more than 40 years ago on 6502 around Digital and Teletype and custom made telecommunications and high power radio transceiver equipment in an industrial electronics manufacturing facility for computers in the COMECON (Eastern Bloc) as a pre-school practice as a third generation engineer. I am also a masters engineering degree with double excellence and more than 25 years of professional UNIX applied experience in computer hardware and internet services provisioning in broadcast, electronics production and manufacturing, and hosting and services with thousands of machines and customers. I have read and written about and on UNIX in 4 natural and many internationally standardised synthetic languages. You do not know me, but now you do know a bit of this and that too.
Speak about yourself when you say "we", because not everyone is your level of progress. Obviously "we" are on the same system but not from the same initial points of time and space, and some of "us" command more systems and machinery for more serious utilisation. There is always a lot more to learn, practice and experience, you're neither completely saturated, nor completely wise until you say so. Thanks for your attention to detail, I am off this thread now too. A lot has happened, regardless of not witnessing it with your own eyes, and there is a lot more to happen further. Have patience, persistence, perseverance, practice, perfection. On 9/25/23, Rudolf Leitgeb <rudolf.leit...@gmx.at> wrote: > "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 ! > >
