On Mon, 19 Aug 2024 21:34:46 -0400, 186282@ud0s4.net wrote:

> As for the flying cars - probably best that they never worked ...
> there'd be flaming junk falling from the skies almost constantly.
> People suck even at 2-D driving.

The point being, they’re almost completely automated -- they’re cars after
all, not conventional aircraft. Possibly even no conventional controls:
just a screen, perhaps, for you to enter your destination, and leave all
the actual driving to the car itself.

The one that could really need to chaos in the skies would be personal
jetpacks. Traffic control would become impossible.

Hmm, I half-recall there was an SF short story along exactly those
lines ...

On Tue, 20 Aug 2024 07:47:18 -0700, Don_from_AZ wrote:

> Maybe during the summer sessions air conditioning was useful, but most
> of the year in Troy what you needed was HEAT!

That’s why we have heat pumps: they work both ways.

On 20 Aug 2024 19:27:53 GMT, rbowman wrote:

> Come winter and the tables turned. We'd be wearing short
> sleeve shirts and the guys upstairs were in parkas.

Seems like, all you needed were suitable gaps to let the cold air descend
from the upper to the lower floor, and let physics take its course.

vallor wrote:
>>
>> Heh ... I remember visiting a county facility when I was still pretty
>> young. The computer room was freezing and the floor was laser-leveled
>> for the benefit of the old-style disk drive units (and I mean
>> "units", you could physically remove a big spool of about 12" wide
>> disks - DO wait until they stop spinning !). There were also the
>> boxes with the spinning tapes and the obligatory card and paper-tape
>> readers.
>>
>> The "cpu chip" was about a cubic METER in size in the middle of the
>> room - DEC I think, PDP-4 or maybe PDP-7 - full of a bunch of circuit
>> boards with zillions of individual transistors and perhaps a few
>> early "chips". Workers/programmers had serial terminals at their
>> desks.

Yeah, I remember the university had that stuff in the 1970s, and also a
"concentrator" that multiplexed 300-baud terminals into an ISDN line.

On Wed, 21 Aug 2024 19:25:29 +0800, Woozy Song <suzyw0ng@outlook.com>
wrote in <va4iri$3rfcv$1@dont-email.me>:

> vallor wrote:

I didn't write the following -- that was "186252".

>>>
>>> Heh ... I remember visiting a county facility when I was still
>>> pretty young. The computer room was freezing and the floor was
>>> laser-leveled for the benefit of the old-style disk drive units
>>> (and I mean "units", you could physically remove a big spool of
>>> about 12" wide disks - DO wait until they stop spinning !). There
>>> were also the boxes with the spinning tapes and the obligatory
>>> card and paper-tape readers.
>>>
>>> The "cpu chip" was about a cubic METER in size in the middle of
>>> the room - DEC I think, PDP-4 or maybe PDP-7 - full of a bunch of
>>> circuit boards with zillions of individual transistors and perhaps
>>> a few early "chips". Workers/programmers had serial terminals at
>>> their desks.
>
> Yeah, I remember the university had that stuff in the 1970s, and also a
> "concentrator" that multiplexed 300-baud terminals into an ISDN line.

No ISDN back then, you may be thinking of ADN.

Our first Net connection at our campus, in 1991, was a 56K ADN, with half
of an X.25 PAD dedicated to IP to CSUNet...so that was 28Kbit/s for a
sizeable campus. (Over 20,000 students, most of them night school.)

Didn't matter much at the time, because there was only one host with
a TCP/IP stack, an HP9000 that ran the campus library card catalog. Took
many months before lab coordinators would allow us to put TCP/IP on
their lab machines. I was a student worker in Computing Services,
so helped with getting the campus on the Net.

I applied to the CIS department for a project, "Special Studies in
Computer Science", and got 3 units setting up a student-access
Linux host at the end of 1992. Students could have email, ftp, etc.
System hardware was a spare Netware server, an HP Vectra RS/20
with 1MB, then later 16MB. Oh, those were the days...

[ng's trimmed]

--
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
OS: Linux 6.11.0-rc4 Release: Mint 21.3 Mem: 258G
"Useless Invention: Ejector seats for helicopters."

On 8/17/2024 9:07 PM, 186282@ud0s4.net wrote:
> On 8/17/24 10:24 PM, vallor wrote:
>> <snip>

>> If you're so inclined to learn on your own...GNU has COBOL.
>>
>> COBC(1)                  User Commands                  COBC(1)
>>
>> NAME
>>         cobc - manual page for cobc 3.1.2.0
>>
>> SYNOPSIS
>>         cobc [options]... file...
>>
>> DESCRIPTION
>>         GnuCOBOL  compiler  for most COBOL dialects with lots of
>>         extensions
>>   _ _ _ _ _ _ _
>>
>> Our local community college used to have a COBOL class, as it led
>> a software consortium that ran COBOL software on mainframes. Looks
>> like they retired those old systems in 2009.
>
>   I'm gonna be heretical and say GNU isn't Real COBOL ... it's
>   just a 'C' translator. There ARE some native COBOL compilers,
>   even a sort of IDE, out there however.
>
>   If you're gonna do Old Systems then you HAVE to be able to set
>   the compiler to respect the OLD standards ... various kinds of
>   fields/instructions/data start at SPECIFIC PLACES ... which
>   corresponded with the old punch-cards. "Relaxed" more modern
>   COBOL/FORTRAN ... great ... but that may NOT get you anywhere
>   on an actual early 60s system.
>
>   I just installed a new box (little BMax) and DID install the
>   GNU COBOL and FORTRAN (and even 'D' and Modula-2 Just Because).
>   Even a FORTH compiler ... like to have all bases covered  :-)
>
>   I'll skip ADA ... DID write some kinda complex-ish stuff for
>   ADA with self-updating lists of linked lists of linked lists ...
>   but the data TYPING is just TOO - had to write some 'cheat'
>   translator functions. Too much ... software should not
>   work hard AGAINST you .......

If I recall correctly, there was some discussion of  a future version of
GNU COBOL being more closely integrated with the GNU compiler ecosystem
so it could generate object files without having to bother with
intermediate C code. My guess is that if this does happen, the change
might not be obvious to the user, who could carry on compiling programs
as before. I'm going to go out on a limb here and say that if it acts
like a COBOL compiler, it's a COBOL compiler, no matter what stages are
involved. It's not as if other GNU compilers translate directly from
source code to object code; there are a number of intermediate steps (if
you compile a C program with -fdump-tree-all, you'll see them).

Louis

(group list trimmed)