[Info-vax] openvms and xterm
chrisq
devzero at nospam.com
Fri May 3 08:03:04 EDT 2024
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...
More information about the Info-vax
mailing list