Re: undocumented command switches -OR- fix documentation fully
On Mon, Sep 25, 2023 at 09:05:40PM +0200, Rudolf Leitgeb 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. Sometimes we're the other guy. I regularly look at other people's tools, trying to figure out what they implement, what they use. Case in point: I added .VARIABLES to our make. It didn't come out of nowhere. It is a documented feature of gnu-make, so I reused the exact same name. I did locate it in the documentation first, because it is documented. I also routinely look at what pkgsrc and freebsd are doing, just so we can grab good ideas from them. Sometimes I even write portable software. Figuring out what goes wrong based on a user's bug report on a system that you don't have is always fun. It is way more fun when you can actually figure it out straight from the documentation. Otherwise, you get to have the fun to try and reproduce their installation.
Re: undocumented command switches -OR- fix documentation fully
Some more self-delineation so you know this is neither anonymous, nor privacy related. Completely formal and real outline of history, nothing to hide, draft outline follows: My (father's) personal, technical school, town and factory station call signs are internationally registered and also recorded in the US and CARTG international amateur radio contest winners (CQ magazine publications) years 1977-1982, with national constructors awards here too for the equipment used to win these world contests and recorded in the national historic record of amateur radio and electronics constructors progress for rationalisations and inventions implementation. We have also other internationally registered amateur radio call signs of people who worked in the facilities here and educated many students in the technical university here, including my graduation. He (father) and I can validate this personally as well, and he had been career long maintaining and repairing the said Digital/DEC, Teletype, Honeywell, IBM, LSI, HP, Siemens, Excellon etc undisclosed equipment and computers for the non-standard, CAD/CAM, drilling and milling, mounting and computerised functional testing services in the manufacturing of electronics and computers in the PCB and mounted electronics manufacturing facility. That I was attending as a kid and throughout my primary and middle school years, in the computer and electronics equipment repair laboratories and the radio club where I spent countless days on computers and machinery from teletypes with tape punch-readers to custom made modems for wireless digital long haul transmissions, and where I later worked on as the lead IT position after my language school and technical university graduation, and the factory complex privatisation in 2002 by the company I was working for as well (internationally) prior to that point. The computers were also internationally exported in the Eastern Bloc and clone 8bit and 16bit Western open and closed licensing during the iron curtain embargo 1980-1990 years. This is the Eastern European country I am talking about: https://en.wikipedia.org/wiki/John_Vincent_Atanasoff?useskin=vector#mw-content-text https://en.wikipedia.org/wiki/History_of_computer_hardware_in_Bulgaria?useskin=vector#mw-content-text These computers were made here apart from many others specialised electronics including then innovate 16-layer PCBs and mounted electronics for export to Japan, and compact scale slot variant industrial instances of the said computers : https://en.wikipedia.org/wiki/Pravetz_computers?useskin=vector#mw-content-text And I have my awards in contests too, diplomas and personal and professional experience with computers, broadcasting live TV before and internet hosting and commerce services after the in house ISP departments for the PCB facilities and multiple other companies that I built myself in lead IT positions, transforming these companies to computerised and digital and internet mode of operation and export, for my country and my region, and internationally in more than one European and Commonwealth country. There is nothing to hide and we're an entire generation of nation wide computer experienced people, from technical OSCAR winners in computer rendered cinematography where many US films are made (here), to a broad range services in the global IT outsourced and near-sourced facilities in automotive and precision instrumentation production and PetaFLOPs supercomputer and AI research facilities. Have you won any international telecommunications competitions and have you produced any computers in your track records with your moon-bounce? I'll send you improvements as time and applicability permits again (as I've done in the past), not even halfway to retirement here. In the meantime, try to not break the system beyond absolute recognition by third party imports if you want any feedback on it and keep up the tempo with work and practice high scrutiny, consistent retains of achieved objectives and missions in the software field too, show some interesting progress your end and make your region internationally renowned too. I've heard and read your "statement" so far by other helpers in the years past, it's repetitive and uninteresting, so make room for more stories and important feedback than canned replies, and personal tease-challenges are met with validation ready results as the project output does too. Back to OpenBSD miscellany talk, folks. The "wholly" ghost in electronics and computing is eagerly awaiting you. On 9/25/23, Christoff Humphries wrote: > It sounds like you'd be a perfect person to submit patches for the > project to improve upon. With someone of your background, I'm > certain they would be of high quality and welcomed. > > Unfortunately ideas and complaints aren't constructive, as they > lead to no real change. Ideas and complains WITH patches is a > different matter, and obviously not the subject of this mailing > list. > >
Re: undocumented command switches -OR- fix documentation fully
It sounds like you'd be a perfect person to submit patches for the project to improve upon. With someone of your background, I'm certain they would be of high quality and welcomed. Unfortunately ideas and complaints aren't constructive, as they lead to no real change. Ideas and complains WITH patches is a different matter, and obviously not the subject of this mailing list. Please harness your energy for greater good versus fighting on the Internet behind anonymity. Otherwise, no matter what your background or experience, it is just as meaningful as me claiming I punched an alligator over the moon. If you want to help, then help. Otherwise it is simply noise. It's that simple. --- Original Message --- On Monday, September 25th, 2023 at 10:34 PM, Eponymous Pseudonym wrote: > > > 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 +, 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 +, 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 > > >
Re: undocumented command switches -OR- fix documentation fully
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 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 +, 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 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 +, 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 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
Re: undocumented command switches -OR- fix documentation fully
He's due a refund on his OS order. Prepare the manager, this guy wants to talk to them. --- Original Message --- On Monday, September 25th, 2023 at 10:08 PM, Rudolf Leitgeb 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 +, 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 +, 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 !
Re: undocumented command switches -OR- fix documentation fully
"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 +, 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 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 +, 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 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 !
Re: undocumented command switches -OR- fix documentation fully
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 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 +, 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 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 !
Re: undocumented command switches -OR- fix documentation fully
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 +, 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 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 !
Re: undocumented command switches -OR- fix documentation fully
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 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 !
Re: undocumented command switches -OR- fix documentation fully
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 ! >
Re: undocumented command switches -OR- fix documentation fully
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 !
Re: undocumented command switches -OR- fix documentation fully
Right, the obvious point overlooked is.. having to poke in the program by chance, on hesitation.. to find out discrepancies, as a confirmation of suspected misalignment between the manual page and the actual program implementation. At individual user level, each time by many system operators on their own wits (and consumers of the program as an interpreter, for example scripts, compilers etc). Instead of just "using" the program and relying that the behaviour is predictable and.. somewhat "truthful" to the actual implementation specifics, by documentation / manual page reference (as expected). Or even consistent over time, and predictable by standards compliance and system specific (cohesive principles). So much for idealisation, the factual state is.. what you do not validate yourself is not validated (who do you trust with that), and it will and does fail you.. all the time, everywhere you look into it and use it thoroughly, continuously, for decades. It does fail you persistently and inevitably, despite working as tested by its implementers. Having to look into the source to confirm the manual page before running the program is a step that is optional, but when you take it and find discrepancies, or failure.. you question the changes leading to that, the changelog and which comes from where and how (also how often). The --version being supported and not documented is a minor point, a totally harmless one, but things that are undocumented will creep, these matters not being addressed do get wider lapses, and not only in a one off case. They become tolerated, the norm and a systemic failure (acceptance and oversight, even on re-evaluations). Yet, we've seen recently, developers have picked up on the call to action, needless to say (as usual), so consider this particular minute "resolved" as a one system operator cry could go that far, for one small point of a "long timed options" case of no such "long options" time. That's not the main point, however. This AWK, that is being constantly re-imported on a continual non-rhythmic pace into OpenBSD from the upstream, which is "neither _true_ (the heck that pretence means), nor the one". It comes from a third party "group" developing it on a "leisure moon(ing) stroll" (carelessly), receives less scrutiny and is sloppily changed routinely, by non-BSD and non-KNF aware GNU / Linux novices in the public (and they can't prove it's better than this criticism outlined). Also, no one can argue with the times and epochs, as things change.. quality and attention to detail degrade in later generation programmers, they are distracted and doing voluntary work on the side pro bono. No auto-type spell checkers and code analysis tools can fix this. Volunteer people are not university graduates any more in the Americas and elsewhere too (for the last 20+ years), and it's going to deteriorate further. Newer tools help, but don't solve it, and these tools do NOT work on (and target) our particular system, and its specifics and properties. That is the objective reality. Other than the obvious "problems" in this particular awk(1) continual reintroduction and "long and slow fix-ups of bugs and subtle behaviour issues" in system tree, it is simply not the OpenBSD quality, and we should be aware of that in public. There is no robust normalised UTF-8 implementation system wide either, and feature creep is set to prevail over quality of programming not only in the many and modernised awk-ren, as it shows in this case for a long(opt) long time so far. As for the compatibility with other systems, you know what to do and how to rationally address these, conformance and coverage of some "portability" is normal and expected (even). No arguments about it.. need to keep up the machine classes and important use cases and adjust the system and extended software according to these necessities. The actual disgusting point is being lied to in the program implementation compared to the program documentation, and it's a foreign problem reintroduced continually. It's not about the UTF-8 or new features all that much, and not about staying legacy and conservatively capsuled in time. Except that it's also part of the what gets ran and what gets proven, and replicated in other programs as custom / non-uniform or manually propagated discrepancies.. Then, there is supposed to be some "trust", that what goes in the system is - if not "robust" and "secure" - at least on that track, or "in long term strive for that and not just acceptance of defeat over this" (you know the speech). There are other larger bulk program being imported continually in the base system and getting exercised like this, and in times even exorcised and excised, it gets the views and attention but does it ever get "fixed" or "normalised" or even conceptually worked on ever for real, other than palliative accommodation? You know the answer. I do know it too, it does not get the real work until these are
Re: undocumented command switches -OR- fix documentation fully
Apart from the obvious troll, I believe there is a point. >From time to time, I go to other projects and try to figure out how far we are from compatibility... Not documenting compat options means that somebody outside the project would have to guess at stuff, instead of just reading the manpage and figuring out "hey, I can just use --version here just like elsewhere". Just because we find long options to be disgusting (tm) doesn't mean we shouldn't try to document what's here to stay. Face it, as much as we would like OpenBSD to stay pure, some compat stuff is there to stay. Let's try not to be more prickly to the outside world than we need, as much as we have a reputation to uphold, shall we ?
Re: undocumented command switches -OR- fix documentation fully
In 5 years, the one true {,g,m}AWK is forked (again) as OpenAWK.. from
GNU awk(1). Undocumented switches are kept for BSD consistency (at
looks). We self-cope with BSD awk(1) in a number of miss-parsed
struggled diffs and give up. Nobody cares. GNU userland is
sup-positioning the BSD. We are one with the new kids. Old men are
no more.. reality check, awk(1) is not Xorg's XTerm, it can be upkept.
Why the undocumented switches are perceived as a failure in this
upkeep work reimport trim beginning, you tell.
On 9/20/23, Theo de Raadt wrote:
> I really don't give a shit.
awk-local(1)
> Eponymous Pseudonym wrote:
>> There is one (old man) in each of you, but "we" see the youth (in you)
>> forever.
Re: undocumented command switches -OR- fix documentation fully
I really don't give a shit. Eponymous Pseudonym wrote: > There is one (old man) in each of you, but "we" see the youth (in you) > forever. > > You know what this is addressing, it's not clouds, but system > conversion principles. Since it is your project, but NOT your system, > surprise me with a solution that I or a broader consensus would > propose, on the domain of: > > * Discrepancies between BSD and GNU and undocumented parts in the BSD > system from imported bulk of "non-OpenBSD" author-ware * > > A call like "get off the list" is fine too, but it's not solving the > problem that pokes your eyes too. Now, let me propose a goal that is > "admitting failure of upkeep in-house of important language utilities > integral to the core of UNIX". Separate it in ports and strip its > core to the system. Documentation is part of that, the split would be > worth it on parts of the system that are exercised a lot, this one is > considered moot? AWK as in the tool that compiler parsers peruse? > > You're _exactly_ interested in this, but it might be too late for this > kind of effort.. in OpenBSD in 2025. Is it too late and too thin of > an edge to walk on? > > awk-local(1) when? > > On 9/20/23, Theo de Raadt wrote: > > Old man yells at cloud. > > Yes.
Re: undocumented command switches -OR- fix documentation fully
There is one (old man) in each of you, but "we" see the youth (in you) forever. You know what this is addressing, it's not clouds, but system conversion principles. Since it is your project, but NOT your system, surprise me with a solution that I or a broader consensus would propose, on the domain of: * Discrepancies between BSD and GNU and undocumented parts in the BSD system from imported bulk of "non-OpenBSD" author-ware * A call like "get off the list" is fine too, but it's not solving the problem that pokes your eyes too. Now, let me propose a goal that is "admitting failure of upkeep in-house of important language utilities integral to the core of UNIX". Separate it in ports and strip its core to the system. Documentation is part of that, the split would be worth it on parts of the system that are exercised a lot, this one is considered moot? AWK as in the tool that compiler parsers peruse? You're _exactly_ interested in this, but it might be too late for this kind of effort.. in OpenBSD in 2025. Is it too late and too thin of an edge to walk on? awk-local(1) when? On 9/20/23, Theo de Raadt wrote: > Old man yells at cloud. Yes.
Re: undocumented command switches -OR- fix documentation fully
Old man yells at cloud.
Re: undocumented command switches -OR- fix documentation fully
> I'm aware that i'm replying to an obvious troll. You mean undocumented switches are abuse to the system operators. So, stop trolling and fix the documentation or remove undocumented switches. The sooner the better, man/doc support is your skill. Not smearing, work accordingly! > Just clarifying what's going on here for bystanders who might feel confused. You're not aware yourself, Ingo, as usual for you. Save yourself the postage fare of your volumEnous strives. Fix manual the page of awk(1) or remove long options for BSD and let it persist in ports and GNU utilities. You're thus mixing and mismatching and covering it up in docs. > CVSROOT:/cvs > Module name:src > Changes by: mill...@cvs.openbsd.org 2023/09/20 10:57:12 > > Modified files: > usr.bin/awk: main.c > > Log message: > Support --version option like upstream awk but don't document it. > > Upstream awk has supported --version for a long time but does not > support -V like our awk does. Both options are supported by gawk. > This is perfectly in line with OpenBSD project goals. How do you know what this is, if you're speaking your own opinion. Coordinate somewhat? > Usually, we do not support long options at all because their "YOU" again > very existence violates POSIX and because, if a programs needs > more options than there are letters in the alphabet, that usually > means the program was seriously misdesigned. Overly opinionated, rejected. Long options is part of some reimplementation utilities like openrsync(1) etc, and POSIX is derived after BSD, which is dishonoured in GNU utilities and extended long options are brought with them which are UNDOCUMENTED HERE. WTF IS THIS! > In some cases, some long options that are synonymous with short > options are so widely used that supporting them *for compatibility > purposes only* makes the life easier for some people, for example > for our porting team. NO. Long options are used in scripts for declarative programming where your GNU info(1) documentation is inconveniencing you. > In those cases, supporting them without > cluttering up the documentation is a perfectly sane approach, in NO. Not EVER. Either in the program and documented or foregone. > particular when the option is as useless as -V in the first place. > Note that most OpenBSD programs, for good reasons, do not provide > an option to print any version number in the first place. It's not about versions, do not skew the topic of fixing undocumented switches. > In some rare cases, practical considerations make it seem worthwhile > to make an exception and provide a long option - usually popularized by > GNU in open defiance of POSIX - that does not have a short equivalent. > In such cases, we do usually document the long option. But that's not > the case here. TLDR; > None of these are hard rules, common sense and good judgement is > always needed, but i certainly agree with what Todd did in this case. Yes, you agree, I do not, and many would NOT. Now, this is MY $opinion. Your blind vote is always amazingly clueless at first draft. What are undocumented switches today? Tomorrow? In 25 years of back-porting monsters? > So everybody, please refrain from insulting Todd who is just doing > some good work here, for free, and for everybody's benefit. That's not the point, Ingo. Write me an autobiographic bug report on fixing the discrepancy, NO? 3-line diff or bust.
Re: undocumented command switches -OR- fix documentation fully
I'm aware that i'm replying to an obvious troll. Just clarifying what's going on here for bystanders who might feel confused. > CVSROOT:/cvs > Module name:src > Changes by: mill...@cvs.openbsd.org 2023/09/20 10:57:12 > > Modified files: > usr.bin/awk: main.c > > Log message: > Support --version option like upstream awk but don't document it. > > Upstream awk has supported --version for a long time but does not > support -V like our awk does. Both options are supported by gawk. This is perfectly in line with OpenBSD project goals. Usually, we do not support long options at all because their very existence violates POSIX and because, if a programs needs more options than there are letters in the alphabet, that usually means the program was seriously misdesigned. In some cases, some long options that are synonymous with short options are so widely used that supporting them *for compatibility purposes only* makes the life easier for some people, for example for our porting team. In those cases, supporting them without cluttering up the documentation is a perfectly sane approach, in particular when the option is as useless as -V in the first place. Note that most OpenBSD programs, for good reasons, do not provide an option to print any version number in the first place. In some rare cases, practical considerations make it seem worthwhile to make an exception and provide a long option - usually popularized by GNU in open defiance of POSIX - that does not have a short equivalent. In such cases, we do usually document the long option. But that's not the case here. None of these are hard rules, common sense and good judgement is always needed, but i certainly agree with what Todd did in this case. So everybody, please refrain from insulting Todd who is just doing some good work here, for free, and for everybody's benefit. Now, let's please stop this thread and discuss something relevant. Yours, Ingo
