From: noemail@basdxcqvbe.com
On Wed, 7 Jul 2021 07:03:27 -0700 (PDT)
Joe Monk wrote:
> > I've implemented a C library, a C compiler, and an
> > OS written in C on the mainframe, and I have no
> > idea what you are talking about.
> >
> > C is a perfectly fine match for the S/3X0 hardware.
>
> Lets be real.
Ok.
> You havent "implemented" anything on a mainframe.
You're wrong about that (two mainframes),
but I'm speaking of myself here, not Paul.
You simply don't know if Paul has had any
mainframe experience in the past. AFAICT,
you're guessing about his lack of experience,
unless you know him IRL or from somewhere else.
> You've taken an *emulator*,
> bent it around to fit your definitions,
> and then written code to run on that.
That my be true, but it doesn't disqualify any
past mainframe experience Paul may have had.
I.e., he may be using the emulator now, because
he no longer has access to a mainframe he once
used, e.g., at work or school.
> Nobody in real life will implement your C
> compiler on an in production mainframe,
That may be true, but IMO not for the reasons
you cited below. Generally, mainframes have
their own compiler tool chain. I.e., they
don't use open source. However, sometimes
they do provide related open source tools.
So, everything is there, sometimes, to
compile GCC.
> first because they cant get it past the info
> security dept
I disagree.
If management has decided to use the project, the
programmers will be allowed to have access to the
code for it. You forget that the management at
most companies is usually hierarchical, and what the
"Bosses" say goes. Period. No exceptions. Get it
done. Now, the "info security dept" may take some
precautions here to CYA, like doing virus scans,
providing cleaned copies via media instead of direct
Internet access or such, or using isolated machines
for development, but the programmers will be provided
with the code base, once the management decision has
been made to use it. If the "info security dept"
refuses for some reason, they'll be forced to
deal management over the issue, which they don't
want to do. (BTDT)
> and second because GCC 3.2.3 is so old that
> it wont pass audit.
I disagree.
If someone in management decided to use Paul's
project on a mainframe, then it'll be used.
Their programmer underlings will have to start with
whatever he provided, including an obsolete version
of a C compiler. Then, if the requirement is to
"pass audit", they'll need to work their way
up through the various GCC versions, ensuring
correct compilation and operation, in order to pass
their quality control audit process.
Also, dead code, such as an obsoleted compiler
version, is statistically safer to start
development from, because the code base isn't
being actively modified, which frequently
introduces new, unknown, or undetectable bugs,
which is typically more of them than what dead
code has. The bugs for dead code have frequently
identified and thoroughly documented, i.e., known.
You can always deal with a known entity, but not
an unknown one.
> (continuing reasons for non-use)
I think the real reason his OS won't be used is
that there is no real use or need for it, but that
can be said of every OS developer I've seen here,
except for wolfgang who sold his OS commercially.
Generally, people accept what they have and are
comfortable with, unless it's a larger leap forward,
e.g., paper to computer, cellphone to smartphone.
In other words, incremental advances or retro
technology won't be accepted widely. At best,
most of the people here are just demonstrating
different OS implementations for their own
personal development, pride, etc.
So, Joe what OS development have you been doing?
--
What is hidden in the ground, when found, is hidden there again?
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
