On Tue, 30 Apr 2024 18:50:55 +0100, chrisq wrote:

> Really, just for networking ?

You seem to have a very simplistic idea of what “networking” is all
about. Maybe, given the group we’re in, your experience dates from, I
don’t know, DECnet days? Netware, maybe?

Here’s the kind of stuff we have to deal with in a modern network
stack:
<https://www.freedesktop.org/software/systemd/man/latest/systemd.netdev.html>

On Sat, 27 Apr 2024 22:37:04 -0400, Arne Vajhøj wrote:

> On 4/27/2024 10:15 PM, Lawrence D'Oliveiro wrote:
>> On Sat, 27 Apr 2024 09:10:14 -0400, Arne Vajhøj wrote:
>>>
>>> I suspect docker is a good example of something that require a real
>>> Linux kernel.
>>
>> Microsoft were trying to implement Docker natively on Windows at one
>> point; wonder why they gave up?
>
> Docker for Windows is available.

It’s a dead product. Microsoft stopped recommending it for new deployments
a long while ago.

John Dallman <jgd@cix.co.uk> wrote:
>In article <v0lm82$2gs$1@panix2.panix.com>, kludge@panix.com (Scott
>Dorsey) wrote:
>
>> Yes! And the odds are that if I got your binary distribution I
>> could probably make it run fine on Slackware (without systemd)
>> after spending an afternoon or two playing with libraries and
>> moving files around. Because Linux distributions don't vary
>> THAT much.
>>
>> But, were I to do that, if I called you for support on your
>> software and explained I was running it on Slackware, the odds
>> are that the first thing you would do would be to tell me to
>> move it to a supported RH system.
>
>I can do better than that. Assuming Distrowatch's page on Slackware is
>accurate, I can tell you that it should run on Slackware 15.0 or later
>and definitely won't run on 14.2 or earlier. That much, I can get from
>the glibc and gcc versions.
>
>If it won't run for you on 15.0 or later, then I'll ask you to try a RHEL
>work-alike, to eliminate the possibility that it's something about your
>local setup.
>
>If it works on Rocky and not on Slackware 15.0, then I'll start asking
>more detailed questions and getting a Slackware VM set up.

All I can say is that you're a lot more helpful toward customers than the
folks at Mathworks are.... and I suspect you are linking in a lot fewer
libraries than their bloated code does.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <v0s562$ehh$1@panix2.panix.com>, kludge@panix.com (Scott
Dorsey) wrote:

> All I can say is that you're a lot more helpful toward customers
> than the folks at Mathworks are....

I'm supplying mathematical modelling libraries to ISVs. I have to be
reasonably helpful.

> and I suspect you are linking in a lot fewer libraries than
> their bloated code does.

You're right. I'm only using glibc and the GCC language run-times. It
makes life a lot simpler.

John

On 5/1/2024 4:29 AM, John Dallman wrote:
> In article <v0s562$ehh$1@panix2.panix.com>, kludge@panix.com (Scott
> Dorsey) wrote:
>> All I can say is that you're a lot more helpful toward customers
>> than the folks at Mathworks are....
>
> I'm supplying mathematical modelling libraries to ISVs. I have to be
> reasonably helpful.
>
>> and I suspect you are linking in a lot fewer libraries than
>> their bloated code does.
>
> You're right. I'm only using glibc and the GCC language run-times. It
> makes life a lot simpler.

No BLAS, LAPACK, Octave etc.?

Arne

In article <v0tcft$35i5j$1@dont-email.me>, arne@vajhoej.dk (Arne Vajh�j)
wrote:
> On 5/1/2024 4:29 AM, John Dallman wrote:
> > In article <v0s562$ehh$1@panix2.panix.com>, kludge@panix.com
> > I'm supplying mathematical modelling libraries to ISVs. I have to
> > be reasonably helpful.
> >
> >> and I suspect you are linking in a lot fewer libraries than
> >> their bloated code does.
> > You're right. I'm only using glibc and the GCC language
> > run-times. It makes life a lot simpler.
>
> No BLAS, LAPACK, Octave etc.?

Nope. Not that kind of modelling.

John

Well, your assumptions illustrate your own background, which was
perhaps python or web weeny programming, where anything goes, but
perhaps, like you, assuming too much ?. Years since vms here, around
5.4, but even then, never liked decnet and had third party tcp/ip app
installed. However, VMS and some others, eg: Solaris, were designed
and implemented from classic software engineering principles, which
accounts for their reliability, whatever their other failings.

Real time embedded background here, where 3000 line source files
and 70 odd header includes would not pass muster anywhere. It shows
complete disregard for system design structure and hierarchy. The file
mentioned, the first looked at, was pulled because of experience of
network programming. But, how does one write a test harness for such
a module ?, or carry out any serious testing, other than, "it seems
to work, so ship it" ?. Where is the doc that describes how it all
works, in detail, flow / state charts etc, so some poor sop can
maintain it in the future at minimum cost ?.

The requirements for software engineering are different from
web weeny programming. Modules tend to be small, so that test harness
can be written to verify them. Depending on application area, not
always done, but there has to be some process to ensure code quality,
and compliance with original system spec.

Software development costs often dwarf project budgets and ongoing
maintenance can cost multiple times initial development
costs, so it's the duty of the original designer and programmer to
document the code, including commentary within. Yes, it's the fashion
to write commentless code these days, but just lazyness, or in some
cases, intentional obfustication to hide internal workings or hacks.
Well designed systems and modules hide functionality, minimise cross
dependencies, and typically need few includes. I guess that's a
lost cause with Linux, which seems to pull in dozens of seemingly
unrelated packages at times, because of opaque cross dependencies.
How that sort of thing is debugged and proven is anybody's guess.

tldr: In short, systemd looks like a cess pit of hacks, but go
on, try to defend it if you will. Just what is the usp for such an
idea ?.

>
> Here’s the kind of stuff we have to deal with in a modern network
> stack:
>
<https://www.freedesktop.org/software/systemd/man/latest/systemd.netdev.html>

Deflection and excuses, failing to address the issues raised...

On 4/30/24 23:56, Lawrence D'Oliveiro wrote:
> On Sun, 28 Apr 2024 12:22:03 +0100, chrisq wrote:
>
>> The way that so much of the unix infrastructure has been replaced,
>> coercing the system to suit the needs of systemd ...
>
> For example?

Normally run FreeBSD for development, but needed to run a current
version of Linux, to test against an open source project, that
it would build and run without issue. Installed latest Xubuntu and
Debian, both of which operate under systemd, with no opout at
install time. Also, that it would build and run under cygwin
windows.

All looks good at desktop level, but the networking config didn't
stick without a reboot, and things like ifconfig, ntp, inetd and
other stuff was missing. It's also not clear how to remove the
systemd stuff, without affecting things like eg: the desktop gui,
so yes, a lot load of stuff under the hood that I don't need.
Here, less is more and the simplest possible system will always
be the most reliable, so long as the essentials are there.

If you like it, use it, but looks like a load of cack to me, and
see the other reply to you post about the sources and system
design in general...

On 4/30/24 18:00, Chris Townley wrote:
> On 30/04/2024 17:36, chrisq wrote:
>> On 4/30/24 06:23, motk wrote:
>>> On 28/04/2024 8:57 pm, chrisq wrote:
>>>
>>> [absolute nonsense]
>>>
>>> OK, you should probably just not express any opinions here. You're
>>> clearly beyond the horizon.
>>>
>>
>> So, what did you disagree with in what was written, or perhaps you
>> think large corporations are full of altruistic love first, rather
>> than grasping for profit ?. Just having a fit is not a valid
>> response :-).
>>
>> Anyway, didn't red hat sell out to ibm just recently, and didn't
>> pottying go to work for Microsoft ?.
>>
>
> IBM completed the purchase of Red Hat in 2019
>

Thanks, no doubt some cooperation long before that, just as red hat
are also connected to Oracle for their Linux offering.

As Linux becomes aver more absorbed by commercial interests,
expect far less transperency and more control...

On 5/3/2024 8:57 AM, chrisq wrote:
> On 4/30/24 18:00, Chris Townley wrote:
>> On 30/04/2024 17:36, chrisq wrote:
>>> Anyway, didn't red hat sell out to ibm just recently, and didn't
>>> pottying go to work for Microsoft ?.
>>>
>>
>> IBM completed the purchase of Red Hat in 2019
>
> Thanks, no doubt some cooperation long before that, just as red hat
> are also connected to Oracle for their Linux offering.

I think Oracle is more connected to Redhat than Redhat is connected
to Oracle.

:-)

Oracle Linux is another RHEL clone, so Oracle obviously like Redhat.

Redhat is not so happy with the cloners. And if I were to guess
then they are more angry with Oracle a multi B$ company than with
Rocky a very small company.

Arne

On 5/3/2024 8:03 AM, chrisq wrote:

> Yes, it's the fashion
> to write commentless code these days,

Since when?

If so, then things are worse than I could imagine.

The end of the world, caused by a bugcheck?

Something like that was mentioned at DECUS maybe 40 years ago. But we're still
here today ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/3/2024 10:16 AM, Dave Froble wrote:
> On 5/3/2024 8:03 AM, chrisq wrote:
>>  Yes, it's the fashion
>> to write commentless code these days,
>
> Since when?
>
> If so, then things are worse than I could imagine.

I will claim that the "recommended approach"
today actually is to use comments.

Clean Code, Code Complete etc..

Note though that there is a strong focus on useful
comments vs useless comments.

Useless comments are comments that explains what
the code does, but if the reader knows the programming
language, then those are redundant because the code
already provide that information, and they are in fact
bad because they clutter up the code.

Useful comments are comments that explain why the code
does what it does.

Super simple example useless:

// add 1 to ix
ix = ix + 1

Super simple example useful:

// skip separating comma
ix = ix + 1

But "recommended approach" and "used everywhere" are
of course two different things.

In general the overall picture of software quality is
very mixed. Some good, a lot ok and some bad. Maybe
even a lot bad.

The number of software developers has increased x10 or more.
And no surprise the average skill level of 30 million
software developers are lower than than of 3 million software
developers.

Current fashions in development methodologies does not
favor strict processes.

There may also be a generational thing of "I will do as
I am told" vs "I will do as I want to".

So in the real world some write useless comments because
they don't know better, some write no comments because
they can get away with it and some write no comments
because the feel very cool by proclaiming that
"code should be self-explanatory".

And some still write useful comments because they got it.

Arne

On 5/3/2024 11:41 AM, Arne Vajhøj wrote:
> On 5/3/2024 10:16 AM, Dave Froble wrote:
>> On 5/3/2024 8:03 AM, chrisq wrote:
>>> Yes, it's the fashion
>>> to write commentless code these days,
>>
>> Since when?
>>
>> If so, then things are worse than I could imagine.
>
> I will claim that the "recommended approach"
> today actually is to use comments.
>
> Clean Code, Code Complete etc..
>
> Note though that there is a strong focus on useful
> comments vs useless comments.
>
> Useless comments are comments that explains what
> the code does, but if the reader knows the programming
> language, then those are redundant because the code
> already provide that information, and they are in fact
> bad because they clutter up the code.
>
> Useful comments are comments that explain why the code
> does what it does.
>
> Super simple example useless:
>
> // add 1 to ix
> ix = ix + 1
>
> Super simple example useful:
>
> // skip separating comma
> ix = ix + 1
>
> But "recommended approach" and "used everywhere" are
> of course two different things.
>
> In general the overall picture of software quality is
> very mixed. Some good, a lot ok and some bad. Maybe
> even a lot bad.
>
> The number of software developers has increased x10 or more.
> And no surprise the average skill level of 30 million
> software developers are lower than than of 3 million software
> developers.
>
> Current fashions in development methodologies does not
> favor strict processes.
>
> There may also be a generational thing of "I will do as
> I am told" vs "I will do as I want to".
>
> So in the real world some write useless comments because
> they don't know better, some write no comments because
> they can get away with it and some write no comments
> because the feel very cool by proclaiming that
> "code should be self-explanatory".
>
> And some still write useful comments because they got it.
>
> Arne
>

Well, we've now endured weeks of discussion about Unix, Linux, systemd, and
such, on c.o.v, so while the following could be considered rather verbose, I'm
not going to feel the following is useless spamming of the group.

:-)

The following is some snippets from what was basically a research program, and I
consider commenting such should be rather terse. For production programs I'd
want a lot more.

First, declare the purpose. Shouldn't this always be done?

!********************************************************************
!
! Program: TCP_PEEK.BAS
! Function: Test Using TCP/IP Sockets as a Listener
! Version: 1.00
! Created: 01-Dec-2011
! Author(s): DFE
!
! Purpose/description:
!
! This program will set up TCP/IP sockets to allow
! itself to listen for connection requests. When
! a connection request is received, this program
! will accept the connection, and then attempt to
! PEEK the message, ie; read it but leave it available
! to be re-read.
!
!********************************************************************

When using custom defined structures, it might be nice to know what they will be
used for.

!**************************************************
! Declare Variables of User Defined Structures
!**************************************************

DECLARE IOSB_STRUCT IOSB, ! I/O status blk &
ITEMLIST_2 SERVER.ITEMLST, ! Server item list &
ITEMLIST_2 SOCKOPT.ITEMLST, ! Socket options list &
ITEMLIST_2 REUSEADR.ITEMLST, ! Reuse adr list &
ITEMLIST_3 CLIENT.ITEMLST, ! Client item list &
SOCKET_OPTIONS LISTEN.OPTN, ! Socket options &
SOCK_ADDR CLIENT.ADR, ! Client IP adr/port &
SOCK_ADDR SERVER.ADR, ! Server IP adr/port &
BUFF CLIENT.NAME, ! Client name buffer &
BUFF SERVER.NAME, ! Server name buffer &
IP_ADR IP, ! Ip address &
BUFF MSG ! Message buffer

I consider the following rather terse. Either the programmer knows how to use
system services, or perhaps remedial training is called for.

!**************************************************
! Assign channels to 'TCPIP$DEVICE:'
!**************************************************

Dev$ = "TCPIP$DEVICE:"

Stat% = SYS$ASSIGN( Dev$ , ListenCh% , , )
If ( Stat% And SS$_NORMAL ) = 0%
Then E$ = FnVMSerr$( Stat% )
Print #KB%, "Unable to assign listener channel - "; E$
GoTo 4900
End If

Print #KB%, "Internal VMS channel for listener socket:"; ListenCh%

Stat% = SYS$ASSIGN( Dev$ , ClientCh% , , )
If ( Stat% And SS$_NORMAL ) = 0%
Then E$ = FnVMSerr$( Stat% )
Print #KB%, "Unable to assign client channel - "; E$
GoTo 4900
End If

However, when details might be helpful, there is usually never too much.

!**************************************************
! Create Listener socket
! Bind server's IP address and port # to listener
! socket, set socket as a passive socket
! Note: we used to do this in 2 calls, but can be combined
!**************************************************

LISTEN.OPTN::PROTOCOL% = TCPIP$C_TCP ! Listener socket optn
LISTEN.OPTN::TYP$ = Chr$(TCPIP$C_STREAM)
LISTEN.OPTN::AF$ = Chr$(TCPIP$C_AF_INET)

SOCKOPT.ITEMLST::LEN% = 8% ! Socket options buffer
SOCKOPT.ITEMLST::TYP% = TCPIP$C_SOCKOPT
SOCKOPT.ITEMLST::ADR% = Loc(REUSEADR.ITEMLST::Len%)

REUSEADR.ITEMLST::LEN% = 4% ! Reuse adr (port #)
REUSEADR.ITEMLST::TYP% = TCPIP$C_REUSEADDR
REUSEADR.ITEMLST::ADR% = Loc(ReuseAdrVal%)

ReuseAdrVal% = 1% ! Set to 'True'

SERVER.ITEMLST::LEN% = 16% ! Server item list
SERVER.ITEMLST::TYP% = TCPIP$C_SOCK_NAME
SERVER.ITEMLST::ADR% = Loc(SERVER.ADR::Fam%)

SERVER.ADR::Fam% = TCPIP$C_AF_INET ! Server Ip adr/port
SERVER.ADR::PORT% = SWAP%(ServerPort%)
SERVER.ADR::IP.ADR% = TCPIP$C_INADDR_ANY
SERVER.ADR::ZERO1% = 0%
SERVER.ADR::ZERO2% = 0%

BACKLOG% = 1%

Stat% = SYS$QIOW( , ! Event flag &
ListenCh% By Value, ! VMS channel &
IO$_SETCHAR By Value, ! Operation &
IOSB::Stat%, ! I/O status block &
, ! AST routine &
, ! AST parameter &
LISTEN.OPTN::Protocol%, ! P1 &
, ! P2 &
SERVER.ITEMLST::Len%, ! P3 - local socket nam
e &
BACKLOG% By Value, ! P4 - connection backl
og &
SOCKOPT.ITEMLST::Len%, ! P5 - socket options &
) ! P6

If ( Stat% And SS$_NORMAL ) = 0%
Then E$ = FnVMSerr$( Stat% )
Print #KB%, "Unable to queue create and bind listener socket - "
; E$
GoTo 4900
End If

If ( IOSB::Stat% And SS$_NORMAL ) = 0%
Then Stat% = IOSB::Stat%
E$ = FnVMSerr$( Stat% )
Print #KB%, "Unable to create and bind listener socket - "; E$
GoTo 4900
End If

My opinion is, the above is essential, without it, there would be much studying
of code, wondering what is being referenced, and such. I always use one line
for each argument in a QIO and such, which makes it very clear what is
happening. Without that, even the best will still have some "fun" reading the
code to figure out what is happening.

In article <v12nn8$i674$1@dont-email.me>, arne@vajhoej.dk (Arne Vajh�j)
wrote:

> Oracle Linux is another RHEL clone, so Oracle obviously like Redhat.
>
> Redhat is not so happy with the cloners. And if I were to guess
> then they are more angry with Oracle a multi B$ company than with
> Rocky a very small company.

Oracle gets money that would otherwise likely go to Red Hat; their Linux
isn't a whole lot cheaper than RHEL, whereas Rocky and Alma are free.

Oracle are members of the recently formed Open Enterprise Linux Alliance,
along with CIQ (who produce Rocky) and SUSE.

John

In article <v130js$k7o6$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 5/3/2024 10:16 AM, Dave Froble wrote:
>> On 5/3/2024 8:03 AM, chrisq wrote:
>>>  Yes, it's the fashion
>>> to write commentless code these days,
>>
>> Since when?
>>
>> If so, then things are worse than I could imagine.
>
>I will claim that the "recommended approach"
>today actually is to use comments.
>
>Clean Code,

Clean Code specifically suggests that comments should be
avoided. I believe he wrote that he considers comments, "a
failure." Of course, that's Robert Martin, who knows very
little and is a mediocre programmer, so take anything that he
says with a very large dose of salt.

>Code Complete etc..
>
>Note though that there is a strong focus on useful
>comments vs useless comments.
>
>Useless comments are comments that explains what
>the code does, but if the reader knows the programming
>language, then those are redundant because the code
>already provide that information, and they are in fact
>bad because they clutter up the code.

As with most generalities, this is true most of the time, but
not all of the time.

When an implementation is not obvious, has very subtle
side-effects, or uses a very complex algorithm, it can be very
useful to explain _what_ the code does. But that's very
different than obviously parroting the code as in the, "add one
to x" example that always pops up when this subject comes up.

>Useful comments are comments that explain why the code
>does what it does.
See above.

>[snip]
>// skip separating comma
>ix = ix + 1

Perhaps. But it may be possible to write this in a way that is
much more obvious, without the comment. Here, given context we
may assume that, `ix` is some kind of index into a buffer that
contains string data. In this case, we may be able to write
something like this:

size_t
advance_if_char_matches(const *buffer, size_t index, char ch)
{ if (buffer[index] == ch)
index++;
return index;
}

// ...
ix = advance_if_char_matches(str, ix, ',');

I think it's less obvious, but some C programmers might write
something like:

Lexical analyzers in compilers frequently use code like this to
advance state when matching lexemes. Parsers do something
similar when matching tokens.

Even better, of course, would be to use languages that don't
require integer-indexed strings.

- Dan C.

On 5/3/2024 8:38 PM, Dan Cross wrote:
> In article <v130js$k7o6$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/3/2024 10:16 AM, Dave Froble wrote:
>>> On 5/3/2024 8:03 AM, chrisq wrote:
>>>>  Yes, it's the fashion
>>>> to write commentless code these days,
>>>
>>> Since when?
>>>
>>> If so, then things are worse than I could imagine.
>>
>> I will claim that the "recommended approach"
>> today actually is to use comments.
>>
>> Clean Code,
>
> Clean Code specifically suggests that comments should be
> avoided. I believe he wrote that he considers comments, "a
> failure."

That is not an accurate description of what Clean Code
says.

He does say that:

"The proper use of comments is to compensate for our failure
to express ourself in code. Note that I use the word failure."

But on the next page he opens up with:

"Some comments are necessary or beneficial."

And move on with some examples where he does see value in
comments.

So Clean Code does not suggest that comments should be
avoided. It just say that if well written code can make
a comment unnecessary then it is better.

> Of course, that's Robert Martin, who knows very
> little and is a mediocre programmer, so take anything that he
> says with a very large dose of salt.

Ever wondered what Robert Martin think about you?

:-)

>> Note though that there is a strong focus on useful
>> comments vs useless comments.
>>
>> Useless comments are comments that explains what
>> the code does, but if the reader knows the programming
>> language, then those are redundant because the code
>> already provide that information, and they are in fact
>> bad because they clutter up the code.
>
> As with most generalities, this is true most of the time, but
> not all of the time.
>
> When an implementation is not obvious, has very subtle
> side-effects, or uses a very complex algorithm, it can be very
> useful to explain _what_ the code does. But that's very
> different than obviously parroting the code as in the, "add one
> to x" example that always pops up when this subject comes up.
>
>> Useful comments are comments that explain why the code
>> does what it does.
> See above.

An algorithm description should be more a "why" than a "what".

>> [snip]
>> // skip separating comma
>> ix = ix + 1
>
> Perhaps. But it may be possible to write this in a way that is
> much more obvious, without the comment. Here, given context we
> may assume that, `ix` is some kind of index into a buffer that
> contains string data. In this case, we may be able to write
> something like this:
>
> size_t
> advance_if_char_matches(const *buffer, size_t index, char ch)
> {
> if (buffer[index] == ch)
> index++;
> return index;
> }
>
> // ...
> ix = advance_if_char_matches(str, ix, ',');

If the conditional aspect increases robustness and the function
will be used more than one place, then it is all good.

But it does not change much for the comment.

// skip separating comma if present
ix = advance_if_char_matches(str, ix, ',');

Arne

In article <v1366u$lf87$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>:-)
>
>The following is some snippets from what was basically a research program, and I
>consider commenting such should be rather terse. For production programs I'd
>want a lot more.

I hope you won't mind some feedback?

Overall, there's a concept of, "too much of a good thing."

>First, declare the purpose. Shouldn't this always be done?

Yes, but see below.

> !********************************************************************
> !

What does the line of asterisks buy you?

> ! Program: TCP_PEEK.BAS

Why do you need this? Is it not in a file that is already
named, "TCP_PEEK.BAS"? What do you get by repeating it in the
file itself?

> ! Function: Test Using TCP/IP Sockets as a Listener
> ! Version: 1.00
> ! Created: 01-Dec-2011
> ! Author(s): DFE

Why the elaborate formatting of this front matter? What does
some of it even mean? How did you decide that this was version
1.00, for example? (Something like semver is much more useful
than an arbitrary major.minor here.) Is the creation date
useful versus, say, the last modification date?

Moreover, where do you record the history of the module?
Knowing how code has evolved over time can be very useful.

Frankly, all of this is metadata, which is better captured in a
revision control system than in comments at the top of a file,
which can easily get out of date over time.

> !
> ! Purpose/description:

Well, which is it?

> !
> ! This program will set up TCP/IP sockets to allow
> ! itself to listen for connection requests. When
> ! a connection request is received, this program
> ! will accept the connection, and then attempt to
> ! PEEK the message, ie; read it but leave it available
> ! to be re-read.

This is good, but honestly, kind of all you need at the top of
the file.

>When using custom defined structures, it might be nice to know what they will be
>used for.
>
> !**************************************************
> ! Declare Variables of User Defined Structures
> !**************************************************
>
> DECLARE IOSB_STRUCT IOSB, ! I/O status blk &
> ITEMLIST_2 SERVER.ITEMLST, ! Server item list &
> ITEMLIST_2 SOCKOPT.ITEMLST, ! Socket options list &
> ITEMLIST_2 REUSEADR.ITEMLST, ! Reuse adr list &
> ITEMLIST_3 CLIENT.ITEMLST, ! Client item list &
> SOCKET_OPTIONS LISTEN.OPTN, ! Socket options &
> SOCK_ADDR CLIENT.ADR, ! Client IP adr/port &
> SOCK_ADDR SERVER.ADR, ! Server IP adr/port &
> BUFF CLIENT.NAME, ! Client name buffer &
> BUFF SERVER.NAME, ! Server name buffer &
> IP_ADR IP, ! Ip address &
> BUFF MSG ! Message buffer

I don't think that these comments are useful at all, with the
possible exception of the one on IOSB. These comments just
parrot the code. If I saw, "SOCKOPT.ITEMLIST" how is it not
obvious that that is a, "Socket options list"? Note also that
the comment omits the fact that it's an item list, which is a
specific thing, rather than just a generic list. Half of the
item lists are annotated as item lists in the comments, but
the other half are not.

>I consider the following rather terse. Either the programmer knows how to use
>system services, or perhaps remedial training is called for.
>
> !**************************************************
> ! Assign channels to 'TCPIP$DEVICE:'
> !**************************************************
>
> Dev$ = "TCPIP$DEVICE:"
>
> Stat% = SYS$ASSIGN( Dev$ , ListenCh% , , )
> If ( Stat% And SS$_NORMAL ) = 0%
> Then E$ = FnVMSerr$( Stat% )
> Print #KB%, "Unable to assign listener channel - "; E$
> GoTo 4900
> End If
>
> Print #KB%, "Internal VMS channel for listener socket:"; ListenCh%
>
> Stat% = SYS$ASSIGN( Dev$ , ClientCh% , , )
> If ( Stat% And SS$_NORMAL ) = 0%
> Then E$ = FnVMSerr$( Stat% )
> Print #KB%, "Unable to assign client channel - "; E$
> GoTo 4900
> End If

It's also rather repetitive. It'd be better to wrap assignment
in some kind of helper function, IMHO. Without knowing more
about VMS BASIC, however, it's difficult to tell whether one
could do much better.

>However, when details might be helpful, there is usually never too much.
>
> !**************************************************
> ! Create Listener socket
> ! Bind server's IP address and port # to listener
> ! socket, set socket as a passive socket

I'm not sure this comment is accurate: it appears that most of
what this code is doing until the $QIOW is setting up data for
the $QIOW. Something like this may be more useful:

! Initialize IOSB data for listener socket creation,
! then create the socket and bind it to the server's
! IP address with the given port number.

> ! Note: we used to do this in 2 calls, but can be combined

Grammar: "but they were combined." Again, we see how missing
the history can lead to questions: why were they combined, and
when? Is that better somehow, other than the general principle
of doing less work?

> !**************************************************
>
> LISTEN.OPTN::PROTOCOL% = TCPIP$C_TCP ! Listener socket optn
> LISTEN.OPTN::TYP$ = Chr$(TCPIP$C_STREAM)
> LISTEN.OPTN::AF$ = Chr$(TCPIP$C_AF_INET)
>
> SOCKOPT.ITEMLST::LEN% = 8% ! Socket options buffer
> SOCKOPT.ITEMLST::TYP% = TCPIP$C_SOCKOPT
> SOCKOPT.ITEMLST::ADR% = Loc(REUSEADR.ITEMLST::Len%)
>
> REUSEADR.ITEMLST::LEN% = 4% ! Reuse adr (port #)
> REUSEADR.ITEMLST::TYP% = TCPIP$C_REUSEADDR
> REUSEADR.ITEMLST::ADR% = Loc(ReuseAdrVal%)
>
> ReuseAdrVal% = 1% ! Set to 'True'
>
> SERVER.ITEMLST::LEN% = 16% ! Server item list
> SERVER.ITEMLST::TYP% = TCPIP$C_SOCK_NAME
> SERVER.ITEMLST::ADR% = Loc(SERVER.ADR::Fam%)
>
> SERVER.ADR::Fam% = TCPIP$C_AF_INET ! Server Ip adr/port
> SERVER.ADR::PORT% = SWAP%(ServerPort%)
> SERVER.ADR::IP.ADR% = TCPIP$C_INADDR_ANY
> SERVER.ADR::ZERO1% = 0%
> SERVER.ADR::ZERO2% = 0%
>
> BACKLOG% = 1%
>
> Stat% = SYS$QIOW( , ! Event flag &
> ListenCh% By Value, ! VMS channel &
> IO$_SETCHAR By Value, ! Operation &
> IOSB::Stat%, ! I/O status block &
> , ! AST routine &
> , ! AST parameter &
> LISTEN.OPTN::Protocol%, ! P1 &
> , ! P2 &
> SERVER.ITEMLST::Len%, ! P3 - local socket nam
>e &
> BACKLOG% By Value, ! P4 - connection backl
>og &
> SOCKOPT.ITEMLST::Len%, ! P5 - socket options &
> ) ! P6
>
> If ( Stat% And SS$_NORMAL ) = 0%
> Then E$ = FnVMSerr$( Stat% )
> Print #KB%, "Unable to queue create and bind listener socket - "
>; E$
> GoTo 4900
> End If
>
> If ( IOSB::Stat% And SS$_NORMAL ) = 0%
> Then Stat% = IOSB::Stat%
> E$ = FnVMSerr$( Stat% )
> Print #KB%, "Unable to create and bind listener socket - "; E$
> GoTo 4900
> End If
>
>My opinion is, the above is essential, without it, there would be much studying
>of code, wondering what is being referenced, and such. I always use one line
>for each argument in a QIO and such, which makes it very clear what is
>happening. Without that, even the best will still have some "fun" reading the
>code to figure out what is happening.

On Fri, 3 May 2024 21:25:05 -0400, Arne Vajhøj wrote:

> "The proper use of comments is to compensate for our failure to express
> ourself in code. Note that I use the word failure."

Like saying “the proper use of tools is to compensate for our failure to
build all our technology with our bare hands. Note that I use the word
failure”.

On Fri, 3 May 2024 18:42 +0100 (BST), John Dallman wrote:

> Oracle gets money that would otherwise likely go to Red Hat ...

Interesting that they won’t offer their own ZFS next-generation filesystem
product with it, preferring to bundle btrfs instead. Vote of confidence in
your own product over rivals, much?

On Fri, 3 May 2024 13:05:18 +0100, chrisq wrote:

> On 4/30/24 23:56, Lawrence D'Oliveiro wrote:
>
>> On Sun, 28 Apr 2024 12:22:03 +0100, chrisq wrote:
>>
>>> The way that so much of the unix infrastructure has been replaced,
>>> coercing the system to suit the needs of systemd ...
>>
>> For example?
>
> Normally run FreeBSD for development, but needed to run a current
> version of Linux, to test against an open source project, that it would
> build and run without issue. Installed latest Xubuntu and Debian, both
> of which operate under systemd, with no opout at install time.

So why didn’t you try a distro that didn’t have systemd?

> All looks good at desktop level, but the networking config didn't stick
> without a reboot, and things like ifconfig, ntp, inetd and other stuff
> was missing.

ifconfig was superseded by the iproute2 suite years ago, nothing to do
with systemd. But of course systemd builds on that work--why reinvent the
wheel?

And also inetd is one of the many pieces of legacy baggage superseded by
systemd. systemd offers a much more modular way of managing individual
services--either get used to it, or go use something else. The choice, as
always, is up to you.

> It's also not clear how to remove the systemd stuff ...

It’s called “building your own distro”. Go learn from the experts before
attempting this sort of activity yourself.

Have you tried the “Linux From Scratch” course?

In article <v142pi$rkkc$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 5/3/2024 8:38 PM, Dan Cross wrote:
>> In article <v130js$k7o6$1@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 5/3/2024 10:16 AM, Dave Froble wrote:
>>>> On 5/3/2024 8:03 AM, chrisq wrote:
>>>>>  Yes, it's the fashion
>>>>> to write commentless code these days,
>>>>
>>>> Since when?
>>>>
>>>> If so, then things are worse than I could imagine.
>>>
>>> I will claim that the "recommended approach"
>>> today actually is to use comments.
>>>
>>> Clean Code,
>>
>> Clean Code specifically suggests that comments should be
>> avoided. I believe he wrote that he considers comments, "a
>> failure."
>
>That is not an accurate description of what Clean Code
>says.
>
>He does say that:
>
>"The proper use of comments is to compensate for our failure
>to express ourself in code. Note that I use the word failure."
>
>But on the next page he opens up with:
>
>"Some comments are necessary or beneficial."
>
>And move on with some examples where he does see value in
>comments.
>
>So Clean Code does not suggest that comments should be
>avoided. It just say that if well written code can make
>a comment unnecessary then it is better.

That's literally the definition of what "should be avoided"
means in this context. Clean Code is a poorly written book full
of bad advice; it's really best avoided.

> > Of course, that's Robert Martin, who knows very
> > little and is a mediocre programmer, so take anything that he
> > says with a very large dose of salt.
>
>Ever wondered what Robert Martin think about you?

Why would I care? He's not someone I think is significant
enough to warrant my consideration. He'll certainly never make
it into any of the places where I have worked or do work, so the
odds of running into him professionally are essentially zero.

>:-)

I do find it distressing how he has managed to make so many
programmers fall for really bad programming advice.

>>> Note though that there is a strong focus on useful
>>> comments vs useless comments.
>>>
>>> Useless comments are comments that explains what
>>> the code does, but if the reader knows the programming
>>> language, then those are redundant because the code
>>> already provide that information, and they are in fact
>>> bad because they clutter up the code.
>>
>> As with most generalities, this is true most of the time, but
>> not all of the time.
>>
>> When an implementation is not obvious, has very subtle
>> side-effects, or uses a very complex algorithm, it can be very
>> useful to explain _what_ the code does. But that's very
>> different than obviously parroting the code as in the, "add one
>> to x" example that always pops up when this subject comes up.
>>
>>> Useful comments are comments that explain why the code
>>> does what it does.
>> See above.
>
>An algorithm description should be more a "why" than a "what".

For simple algorithms, sure. For things beyond surface-level
complexity, it's really context dependent.

>>> [snip]
>>> // skip separating comma
>>> ix = ix + 1
>>
>> Perhaps. But it may be possible to write this in a way that is
>> much more obvious, without the comment. Here, given context we
>> may assume that, `ix` is some kind of index into a buffer that
>> contains string data. In this case, we may be able to write
>> something like this:
>>
>> size_t
>> advance_if_char_matches(const *buffer, size_t index, char ch)
>> {
>> if (buffer[index] == ch)
>> index++;
>> return index;
>> }
>>
>> // ...
>> ix = advance_if_char_matches(str, ix, ',');
>
>If the conditional aspect increases robustness and the function
>will be used more than one place, then it is all good.
>
>But it does not change much for the comment.
>
>// skip separating comma if present
>ix = advance_if_char_matches(str, ix, ',');

Sure. It's a contrived example. But I would suggest that this
comment is much closer to parroting the code than the earlier
snippet.

- Dan C.

On Fri, 3 May 2024 11:41:47 -0400, Arne Vajhøj wrote:

> Useful comments are comments that explain why the code
> does what it does.

Absolutely agree. The key word is “why” the code does what it does, not
“what” it does (which is trivially obvious from the code itself).

On Fri, 3 May 2024 13:57:43 +0100, chrisq wrote:

> As Linux becomes aver more absorbed by commercial interests, expect far
> less transperency and more control...

“Linux” ≠ “Red Hat”

Open Source is all about choice. But you have to go looking for that
choice, don’t expect someone to dump it in your lap.

On Fri, 3 May 2024 13:03:04 +0100, chrisq wrote:

>> On Tue, 30 Apr 2024 23:04:02 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>> On Tue, 30 Apr 2024 18:50:55 +0100, chrisq wrote:
>>
>>> Really, just for networking ?
>>
>> You seem to have a very simplistic idea of what “networking” is all
>> about. Maybe, given the group we’re in, your experience dates from, I
>> don’t know, DECnet days? Netware, maybe?
>>
>> Here’s the kind of stuff we have to deal with in a modern network stack:
>> <https://www.freedesktop.org/software/systemd/man/latest/systemd.netdev.html>
>
> [blah blah blah]
>
> Real time embedded background here ...
>
> [blah blah blah]

Nope, not a thing related to networking in there that I can see. Just
a whole lot of bluster.

On Fri, 2024-05-03 at 22:58 -0400, Dave Froble wrote:
> > Why do you need this?  Is it not in a file that is already
> > named, "TCP_PEEK.BAS"?  What do you get by repeating it in the
> > file itself?
>
> Doesn't hurt.

I wuill personally sh**t the next coder who put filenames into the
source code. Refactoring files is a huge pain in the arse when renaming
files as you also have to update the filename in the source code.
--
Tactical Nuclear Kittens