What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? Whistling into a telephone while the modem is attached, because your keyboard has a stuck key - something I absolutely don’t miss. Having a computer in a grimy wharehouse with 400 days of uptime & wondering how a reboot might go? steve j ========= 9 Skills Our Grandkids Will Never Have <https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/> 1: Using record players, audio cassettes, and VCRs 2: Using analog phones [ or an Analog Clock ] 3. Writing letters by hand and mailing them 4. Reading and writing in cursive 5. Using manual research methods [ this is a Genealogy site ] 6. Preparing food the old-fashioned way 7. Creating and mending clothing 8. Building furniture from scratch 9. Speaking the languages of their ancestors -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --] Programming an 026 skip card. Inserting the skip card. Using ed in kernel safe mode to fix a broken config file. Threading a half-inch tape in a tape drive. Remembering to insert or remove the write ring. Cleaning floppy disk heads. Manually keying a boot program into an SDS-930. ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Thu, Jun 30, 2022 at 9:14 AM steve jenkin <sjenkin@canb.auug.org.au> wrote: > What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t > have”? > > Whistling into a telephone while the modem is attached, because your > keyboard has a stuck key > - something I absolutely don’t miss. > > Having a computer in a grimy wharehouse with 400 days of uptime & > wondering how a reboot might go? > > steve j > > ========= > > 9 Skills Our Grandkids Will Never Have > < > https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/ > > > > 1: Using record players, audio cassettes, and VCRs > 2: Using analog phones > [ or an Analog Clock ] > 3. Writing letters by hand and mailing them > 4. Reading and writing in cursive > 5. Using manual research methods [ > this is a Genealogy site ] > 6. Preparing food the old-fashioned way > 7. Creating and mending clothing > 8. Building furniture from scratch > 9. Speaking the languages of their ancestors > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin > > [-- Attachment #2: Type: text/html, Size: 3111 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2090 bytes --] Taking floppy disks out of the holders and floating them on the cold air updrafts in computer room false floor. On 6/30/22 9:39 AM, Marc Donner wrote: > Programming an 026 skip card. Inserting the skip card. > Using ed in kernel safe mode to fix a broken config file. > Threading a half-inch tape in a tape drive. Remembering to insert or > remove the write ring. > Cleaning floppy disk heads. > Manually keying a boot program into an SDS-930. > ===== > nygeek.net <http://nygeek.net> > mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> > > > On Thu, Jun 30, 2022 at 9:14 AM steve jenkin > <sjenkin@canb.auug.org.au> wrote: > > What are the 1970’s & 1980’s Computing / IT skills “our grandkids > won’t have”? > > Whistling into a telephone while the modem is attached, because > your keyboard has a stuck key > - something I absolutely don’t miss. > > Having a computer in a grimy wharehouse with 400 days of uptime & > wondering how a reboot might go? > > steve j > > ========= > > 9 Skills Our Grandkids Will Never Have > > <https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/> > > 1: Using record players, audio cassettes, and VCRs > 2: Using analog phones [ or an Analog > Clock ] > 3. Writing letters by hand and mailing them > 4. Reading and writing in cursive > 5. Using manual research methods [ this is a > Genealogy site ] > 6. Preparing food the old-fashioned way > 7. Creating and mending clothing > 8. Building furniture from scratch > 9. Speaking the languages of their ancestors > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin > [-- Attachment #2: Type: text/html, Size: 4993 bytes --]
A fun one: Using folders. People in their early 20s and younger - mostly those who grew up with iPhones, Androids and Ipads - didn't interact with filesystems. Instead, they grew up using apps that handled storage for them. When they wanted a video, they were looking for it in a streaming app, and they used the app's search function. If they were looking at photos, it was much the same. Because of this, as hard as it is to believe, they don't really grok the concept - and this keeps popping up, to my delight. It initially popped into my field of view last year, when an astro professor was running into trouble with undergrad students. The professor was asking the students to put certain data into certain folders, but the students fundamentally didn't understand what "putting certain data in certain folders" meant: https://twitter.com/saavikford/status/1425235201047908359 I love this quote from the professor, though unfortunately the tweet prompting it was deleted. The professor was asked something like "do the students not understand how drawers work?" Her response was, "They fail to grasp that the idea of drawers themselves might exist. Because they have a perfectly valid system of a laundry basket and a robot that retrieves exactly the sock they want when they want it (as I'm finally figuring out). Or something like that, anyway." And this continues to pop up - I saw a reddit thread the other day that brought up entry-level computer science students who are coming in not understanding folders at all. It's being added to the list of abstractions that most people don't interact with day-to-day anymore, and which must be explained. With that said, I have a friend my age (30s) who enjoys bringing up their conviction that the Zoomers are correct, and hierarchical filesystems should go the way of the dinosaur - with searchability/tagging being the correct way to handle storage. That could also be a fun discussion for the ML. One other fun note for the prompt. Someone noted that, working at an apple store, they kept seeing young people use the caps lock key even when just typing the first letter of the sentence; it then clicked that this is closest to how phone keyboards work, and is likely where they got the muscle memory from. Hope you're all having a nice morning, Marshall On Thu, Jun 30, 2022 at 9:40 AM Marc Donner <marc.donner@gmail.com> wrote: > > Programming an 026 skip card. Inserting the skip card. > Using ed in kernel safe mode to fix a broken config file. > Threading a half-inch tape in a tape drive. Remembering to insert or remove the write ring. > Cleaning floppy disk heads. > Manually keying a boot program into an SDS-930. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Thu, Jun 30, 2022 at 9:14 AM steve jenkin <sjenkin@canb.auug.org.au> wrote: >> >> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? >> >> Whistling into a telephone while the modem is attached, because your keyboard has a stuck key >> - something I absolutely don’t miss. >> >> Having a computer in a grimy wharehouse with 400 days of uptime & wondering how a reboot might go? >> >> steve j >> >> ========= >> >> 9 Skills Our Grandkids Will Never Have >> <https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/> >> >> 1: Using record players, audio cassettes, and VCRs >> 2: Using analog phones [ or an Analog Clock ] >> 3. Writing letters by hand and mailing them >> 4. Reading and writing in cursive >> 5. Using manual research methods [ this is a Genealogy site ] >> 6. Preparing food the old-fashioned way >> 7. Creating and mending clothing >> 8. Building furniture from scratch >> 9. Speaking the languages of their ancestors >> >> -- >> Steve Jenkin, IT Systems and Design >> 0412 786 915 (+61 412 786 915) >> PO Box 38, Kippax ACT 2615, AUSTRALIA >> >> mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin >>
I can still remember my amazement when I learned that a floppy or a hard disk wasn't one big file. That's when the light went on that there was a file system. Another one was popen(), I saw the fork in there and my head exploded, for some stupid reason I didn't think that libc would create new processes. One light bulb after another. On Thu, Jun 30, 2022 at 10:08:34AM -0400, Marshall Conover wrote: > A fun one: Using folders. > > People in their early 20s and younger - mostly those who grew up with > iPhones, Androids and Ipads - didn't interact with filesystems. > Instead, they grew up using apps that handled storage for them. When > they wanted a video, they were looking for it in a streaming app, and > they used the app's search function. If they were looking at photos, > it was much the same. Because of this, as hard as it is to believe, > they don't really grok the concept - and this keeps popping up, to my > delight. > > It initially popped into my field of view last year, when an astro > professor was running into trouble with undergrad students. The > professor was asking the students to put certain data into certain > folders, but the students fundamentally didn't understand what > "putting certain data in certain folders" meant: > https://twitter.com/saavikford/status/1425235201047908359 > > I love this quote from the professor, though unfortunately the tweet > prompting it was deleted. The professor was asked something like "do > the students not understand how drawers work?" Her response was, "They > fail to grasp that the idea of drawers themselves might exist. Because > they have a perfectly valid system of a laundry basket and a robot > that retrieves exactly the sock they want when they want it (as I'm > finally figuring out). Or something like that, anyway." > > And this continues to pop up - I saw a reddit thread the other day > that brought up entry-level computer science students who are coming > in not understanding folders at all. It's being added to the list of > abstractions that most people don't interact with day-to-day anymore, > and which must be explained. > > With that said, I have a friend my age (30s) who enjoys bringing up > their conviction that the Zoomers are correct, and hierarchical > filesystems should go the way of the dinosaur - with > searchability/tagging being the correct way to handle storage. That > could also be a fun discussion for the ML. > > One other fun note for the prompt. Someone noted that, working at an > apple store, they kept seeing young people use the caps lock key even > when just typing the first letter of the sentence; it then clicked > that this is closest to how phone keyboards work, and is likely where > they got the muscle memory from. > > Hope you're all having a nice morning, > > Marshall > > On Thu, Jun 30, 2022 at 9:40 AM Marc Donner <marc.donner@gmail.com> wrote: > > > > Programming an 026 skip card. Inserting the skip card. > > Using ed in kernel safe mode to fix a broken config file. > > Threading a half-inch tape in a tape drive. Remembering to insert or remove the write ring. > > Cleaning floppy disk heads. > > Manually keying a boot program into an SDS-930. > > ===== > > nygeek.net > > mindthegapdialogs.com/home > > > > > > On Thu, Jun 30, 2022 at 9:14 AM steve jenkin <sjenkin@canb.auug.org.au> wrote: > >> > >> What are the 1970???s & 1980???s Computing / IT skills ???our grandkids won???t have???? > >> > >> Whistling into a telephone while the modem is attached, because your keyboard has a stuck key > >> - something I absolutely don???t miss. > >> > >> Having a computer in a grimy wharehouse with 400 days of uptime & wondering how a reboot might go? > >> > >> steve j > >> > >> ========= > >> > >> 9 Skills Our Grandkids Will Never Have > >> <https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/> > >> > >> 1: Using record players, audio cassettes, and VCRs > >> 2: Using analog phones [ or an Analog Clock ] > >> 3. Writing letters by hand and mailing them > >> 4. Reading and writing in cursive > >> 5. Using manual research methods [ this is a Genealogy site ] > >> 6. Preparing food the old-fashioned way > >> 7. Creating and mending clothing > >> 8. Building furniture from scratch > >> 9. Speaking the languages of their ancestors > >> > >> -- > >> Steve Jenkin, IT Systems and Design > >> 0412 786 915 (+61 412 786 915) > >> PO Box 38, Kippax ACT 2615, AUSTRALIA > >> > >> mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin > >> -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
On 30 Jun 2022 23:14 +1000, from sjenkin@canb.auug.org.au (steve jenkin): > What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? Tediously typing computer programs into their (or others') systems from listings in printed magazines bought in and brought home from a store (by which I mean the physical, brick-and-mortar kind), only to spend anywhere from minutes to days figuring out why the program doesn't do what the magazine says it will, if it even works at all. This thread should probably be on COFF, not TUHS. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Every time I teach a course that deals with the terminal, I have to have
a complete lecture on files, filesystems and the concept of current
directory. It is a rare exception that I get students who know them from
prior experience. This includes folks into their 40's.
in the spirit of what our grandkids won't have skills (or knowledge) for:
Our grandkids won't go looking for bent pins on their video cables or
know that's why their normally colorful view of the world suddenly tints
cyanish...
or that a crossover's a cable
or that whiz-bang programming languages of the modern era are still
playing catch-up to ALGOL 1960 and other brilliant languages of the 20th
century
or that there was a time when current decided 0's and 1's rather than
voltage
they'll be endlessly frustrated by CD/DVDs even if they can find a
player - some working and some not (writeables have significant
calibration and/or deterioration issues) - oh wait, that last one's not
my grandkids, it's me :).
On 6/30/22 9:08 AM, Marshall Conover wrote:
> A fun one: Using folders.
>
> People in their early 20s and younger - mostly those who grew up with
> iPhones, Androids and Ipads - didn't interact with filesystems.
> Instead, they grew up using apps that handled storage for them. When
> they wanted a video, they were looking for it in a streaming app, and
> they used the app's search function. If they were looking at photos,
> it was much the same. Because of this, as hard as it is to believe,
> they don't really grok the concept - and this keeps popping up, to my
> delight.
>
> It initially popped into my field of view last year, when an astro
> professor was running into trouble with undergrad students. The
> professor was asking the students to put certain data into certain
> folders, but the students fundamentally didn't understand what
> "putting certain data in certain folders" meant:
> https://twitter.com/saavikford/status/1425235201047908359
>
> I love this quote from the professor, though unfortunately the tweet
> prompting it was deleted. The professor was asked something like "do
> the students not understand how drawers work?" Her response was, "They
> fail to grasp that the idea of drawers themselves might exist. Because
> they have a perfectly valid system of a laundry basket and a robot
> that retrieves exactly the sock they want when they want it (as I'm
> finally figuring out). Or something like that, anyway."
>
> And this continues to pop up - I saw a reddit thread the other day
> that brought up entry-level computer science students who are coming
> in not understanding folders at all. It's being added to the list of
> abstractions that most people don't interact with day-to-day anymore,
> and which must be explained.
>
> With that said, I have a friend my age (30s) who enjoys bringing up
> their conviction that the Zoomers are correct, and hierarchical
> filesystems should go the way of the dinosaur - with
> searchability/tagging being the correct way to handle storage. That
> could also be a fun discussion for the ML.
>
> One other fun note for the prompt. Someone noted that, working at an
> apple store, they kept seeing young people use the caps lock key even
> when just typing the first letter of the sentence; it then clicked
> that this is closest to how phone keyboards work, and is likely where
> they got the muscle memory from.
>
> Hope you're all having a nice morning,
>
> Marshall
>
> On Thu, Jun 30, 2022 at 9:40 AM Marc Donner <marc.donner@gmail.com> wrote:
>> Programming an 026 skip card. Inserting the skip card.
>> Using ed in kernel safe mode to fix a broken config file.
>> Threading a half-inch tape in a tape drive. Remembering to insert or remove the write ring.
>> Cleaning floppy disk heads.
>> Manually keying a boot program into an SDS-930.
>> =====
>> nygeek.net
>> mindthegapdialogs.com/home
>>
>>
>> On Thu, Jun 30, 2022 at 9:14 AM steve jenkin <sjenkin@canb.auug.org.au> wrote:
>>> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”?
>>>
>>> Whistling into a telephone while the modem is attached, because your keyboard has a stuck key
>>> - something I absolutely don’t miss.
>>>
>>> Having a computer in a grimy wharehouse with 400 days of uptime & wondering how a reboot might go?
>>>
>>> steve j
>>>
>>> =========
>>>
>>> 9 Skills Our Grandkids Will Never Have
>>> <https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/>
>>>
>>> 1: Using record players, audio cassettes, and VCRs
>>> 2: Using analog phones [ or an Analog Clock ]
>>> 3. Writing letters by hand and mailing them
>>> 4. Reading and writing in cursive
>>> 5. Using manual research methods [ this is a Genealogy site ]
>>> 6. Preparing food the old-fashioned way
>>> 7. Creating and mending clothing
>>> 8. Building furniture from scratch
>>> 9. Speaking the languages of their ancestors
>>>
>>> --
>>> Steve Jenkin, IT Systems and Design
>>> 0412 786 915 (+61 412 786 915)
>>> PO Box 38, Kippax ACT 2615, AUSTRALIA
>>>
>>> mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
>>>
- Add an entry to /etc/termcap. - Try all speeds on your terminal in order to find the good one to connect to your host. Pierre
On 6/30/22 6:14 AM, steve jenkin wrote:
> 9 Skills Our Grandkids Will Never Have
Knowing how to do pre-press layout for paper books
Organizing things hierarchically
[-- Attachment #1: Type: text/plain, Size: 2576 bytes --] - that goes with >>dialing<< the phone and putting it in the rubber cups after you hear the tone from the FSK modem at that other end. - putting your deck into run queue and waiting for your turn to get 5 seconds of compile and 3 seconds of CPU time for a student job - being limited to > .5M of storage (if you had any at all) - If you were an operator - handing a tape change request - starting/stopping the batch system to let students' jobs run - changing the print train - moving a plot tape from the computer to the plotter for output - changing disks - what a disk crash actually sounds like (and looks like on the platters) ᐧ On Thu, Jun 30, 2022 at 9:41 AM Marc Donner <marc.donner@gmail.com> wrote: > Programming an 026 skip card. Inserting the skip card. > Using ed in kernel safe mode to fix a broken config file. > Threading a half-inch tape in a tape drive. Remembering to insert or > remove the write ring. > Cleaning floppy disk heads. > Manually keying a boot program into an SDS-930. > ===== > nygeek.net > mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> > > > On Thu, Jun 30, 2022 at 9:14 AM steve jenkin <sjenkin@canb.auug.org.au> > wrote: > >> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t >> have”? >> >> Whistling into a telephone while the modem is attached, because your >> keyboard has a stuck key >> - something I absolutely don’t miss. >> >> Having a computer in a grimy wharehouse with 400 days of uptime & >> wondering how a reboot might go? >> >> steve j >> >> ========= >> >> 9 Skills Our Grandkids Will Never Have >> < >> https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/ >> > >> >> 1: Using record players, audio cassettes, and VCRs >> 2: Using analog phones >> [ or an Analog Clock ] >> 3. Writing letters by hand and mailing them >> 4. Reading and writing in cursive >> 5. Using manual research methods [ >> this is a Genealogy site ] >> 6. Preparing food the old-fashioned way >> 7. Creating and mending clothing >> 8. Building furniture from scratch >> 9. Speaking the languages of their ancestors >> >> -- >> Steve Jenkin, IT Systems and Design >> 0412 786 915 (+61 412 786 915) >> PO Box 38, Kippax ACT 2615, AUSTRALIA >> >> mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin >> >> [-- Attachment #2: Type: text/html, Size: 4626 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3597 bytes --] a few more ... - the sounds of an ASR 33 - why bang, and splat are called that - the sounds of terminal room - running 'system' diagnostics - what 'dumping core' refers too - rolling an unspooled DECtape up after dropping it and stepping on it, and it still reading - the concept/use of PPT - entering the RIM loader for the PDP-8 from the front panel, so you could load the rest of the boot from PPT - entering the board program into a PDP-8 11/45 without an M792 diode 'ROM' board. - Watching the idle pattern on the lights Note the last 3 can be re-lived with a PiDP-8 <https://streaklinks.com/BGyDfuK4ePmLFWSPRwRm6v_o/https%3A%2F%2Fobsolescence.wixsite.com%2Fobsolescence%2Fpidp-8> or PiDP-11 <https://streaklinks.com/BGyDfuWMjBQsSqgHCA6qh56Y/https%3A%2F%2Fobsolescence.wixsite.com%2Fobsolescence%2Fpidp-11> ᐧ ᐧ On Thu, Jun 30, 2022 at 11:23 AM Clem Cole <clemc@ccc.com> wrote: > > > - that goes with >>dialing<< the phone and putting it in the rubber > cups after you hear the tone from the FSK modem at that other end. > - putting your deck into run queue and waiting for your turn to get 5 > seconds of compile and 3 seconds of CPU time for a student job > - being limited to > .5M of storage (if you had any at all) > - If you were an operator > - handing a tape change request > - starting/stopping the batch system to let students' jobs run > - changing the print train > - moving a plot tape from the computer to the plotter for output > - changing disks > - what a disk crash actually sounds like (and looks like on the > platters) > > ᐧ > > On Thu, Jun 30, 2022 at 9:41 AM Marc Donner <marc.donner@gmail.com> wrote: > >> Programming an 026 skip card. Inserting the skip card. >> Using ed in kernel safe mode to fix a broken config file. >> Threading a half-inch tape in a tape drive. Remembering to insert or >> remove the write ring. >> Cleaning floppy disk heads. >> Manually keying a boot program into an SDS-930. >> ===== >> nygeek.net >> mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> >> >> >> On Thu, Jun 30, 2022 at 9:14 AM steve jenkin <sjenkin@canb.auug.org.au> >> wrote: >> >>> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t >>> have”? >>> >>> Whistling into a telephone while the modem is attached, because your >>> keyboard has a stuck key >>> - something I absolutely don’t miss. >>> >>> Having a computer in a grimy wharehouse with 400 days of uptime & >>> wondering how a reboot might go? >>> >>> steve j >>> >>> ========= >>> >>> 9 Skills Our Grandkids Will Never Have >>> < >>> https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/ >>> > >>> >>> 1: Using record players, audio cassettes, and VCRs >>> 2: Using analog phones >>> [ or an Analog Clock ] >>> 3. Writing letters by hand and mailing them >>> 4. Reading and writing in cursive >>> 5. Using manual research methods >>> [ this is a Genealogy site ] >>> 6. Preparing food the old-fashioned way >>> 7. Creating and mending clothing >>> 8. Building furniture from scratch >>> 9. Speaking the languages of their ancestors >>> >>> -- >>> Steve Jenkin, IT Systems and Design >>> 0412 786 915 (+61 412 786 915) >>> PO Box 38, Kippax ACT 2615, AUSTRALIA >>> >>> mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin >>> >>> [-- Attachment #2: Type: text/html, Size: 6834 bytes --]
On Thu, Jun 30, 2022 at 04:42:20PM +0200, Pierre DAVID wrote:
> - Add an entry to /etc/termcap.
I have to admit that something like 40 years ago, I tried and failed.
Paid Dave Cohrs $20 to write one for me. I remember him laughing at
me because it was trivial for him but I just kept screwing it up.
That and sendmail.cf, I've fought with that file quite a bit, got it
to work but just barely.
> On Jun 30, 2022, at 6:14 AM, steve jenkin <sjenkin@canb.auug.org.au> wrote:
>
> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”?
80s: being able to understand more or less what the whole machine was doing at any given time. I consider myself fortunate that I grew up on 80s micros where the machines were powerful enough to do interesting-to-a-bright-12-year-old things (like, say, Choplifter), but small enough that...well, there's only 64K, only one instruction is operating at a time, the sound-and-video-coprocessor-(if-any)-APIs are tiny, if you're a determined bright 12-year-old, you can figure out how it's doing what it's doing.
This is post-80s, but:
Massive midrange hearing loss in their 40s and 50s because of their late 20s and 30s being spent inside very very noisy datacenters.
Not that I'm bitter. Just it would have been nice if my parents were right and it had been that loud rock 'n' roll rather than, you know, _fans_.
Adam
On 6/30/22, steve jenkin <sjenkin@canb.auug.org.au> wrote:
> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t
> have”?
Not skills, but knowledge of why some things in Unix are the way they are:
o why a memory access violation is reported as "segmentation fault" or
"bus error", and the difference between the two
o why CTRL/D is used to end a shell command line session
o why CTRL/S and CTRL/Q are used for flow control in a shell command
line session
o why an application memory dump after an application crash is called
a core file
-Paul W.
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --] At the risk of going off-topic (Linux and 90's/00's) I'll play too: 1)remembering to set ftp type to binary (that one bit me more than once, at least) 2)learning what a "winmodem" is and avoiding it like the plague! 3)Splitting a partition with FIPS 4)Writing an image to floppy 5)doing anything at all with a floppy, come to think of it 6)Setting jumpers on sound cards and drives 7)learning how to configure XFree86 so that it doesn't blow out your monitor! (never happened to me, but I remember the scary warnings about it: https://www.xfree86.org/4.0.3/chips7.html ) 8)configuring PPP internet On Thu, Jun 30, 2022 at 5:14 AM steve jenkin <sjenkin@canb.auug.org.au> wrote: > What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t > have”? > > Whistling into a telephone while the modem is attached, because your > keyboard has a stuck key > - something I absolutely don’t miss. > > Having a computer in a grimy wharehouse with 400 days of uptime & > wondering how a reboot might go? > > steve j > > ========= > > 9 Skills Our Grandkids Will Never Have > < > https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/ > > > > 1: Using record players, audio cassettes, and VCRs > 2: Using analog phones > [ or an Analog Clock ] > 3. Writing letters by hand and mailing them > 4. Reading and writing in cursive > 5. Using manual research methods [ > this is a Genealogy site ] > 6. Preparing food the old-fashioned way > 7. Creating and mending clothing > 8. Building furniture from scratch > 9. Speaking the languages of their ancestors > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin > > [-- Attachment #2: Type: text/html, Size: 2891 bytes --]
Entering a boot loader using front panel switches.
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --] editing /etc/inittab On 1/7/22 05:24, Michael Huff wrote: > At the risk of going off-topic (Linux and 90's/00's) I'll play too: > 1)remembering to set ftp type to binary (that one bit me more than > once, at least) > 2)learning what a "winmodem" is and avoiding it like the plague! > 3)Splitting a partition with FIPS > 4)Writing an image to floppy > 5)doing anything at all with a floppy, come to think of it > 6)Setting jumpers on sound cards and drives > 7)learning how to configure XFree86 so that it doesn't blow out your > monitor! (never happened to me, but I remember the scary warnings > about it: https://www.xfree86.org/4.0.3/chips7.html ) > 8)configuring PPP internet > > > On Thu, Jun 30, 2022 at 5:14 AM steve jenkin > <sjenkin@canb.auug.org.au> wrote: > > What are the 1970’s & 1980’s Computing / IT skills “our grandkids > won’t have”? > > Whistling into a telephone while the modem is attached, because > your keyboard has a stuck key > - something I absolutely don’t miss. > > Having a computer in a grimy wharehouse with 400 days of uptime & > wondering how a reboot might go? > > steve j > > ========= > > 9 Skills Our Grandkids Will Never Have > > <https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/> > > 1: Using record players, audio cassettes, and VCRs > 2: Using analog phones [ or an Analog > Clock ] > 3. Writing letters by hand and mailing them > 4. Reading and writing in cursive > 5. Using manual research methods [ this is a > Genealogy site ] > 6. Preparing food the old-fashioned way > 7. Creating and mending clothing > 8. Building furniture from scratch > 9. Speaking the languages of their ancestors > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin > [-- Attachment #2: Type: text/html, Size: 4428 bytes --]
Editing /etc/inittab with ed(1).
> On 30 Jun 2022, at 21:43, Robert Stanford via TUHS <tuhs@tuhs.org> wrote:
>
> editing /etc/inittab
>
at the coreboot workshop 2w ago, we were having very weird memory
corruption issues. At some point I popped up dc and started doing base
16 math.
Comment: "that's the first time in my life I've ever seen someone use
dc for hex math"
On Thu, Jun 30, 2022 at 1:49 PM Chris Pinnock via TUHS <tuhs@tuhs.org> wrote:
>
> Editing /etc/inittab with ed(1).
>
> > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS <tuhs@tuhs.org> wrote:
> >
> > editing /etc/inittab
> >
>
When your tty settings are messed up, ed(1) has saved my butt a number of times. Also really pleasant to use on slow modems where just the screen refresh takes a long time. ed foo.c /^busted_function .,.+20p is dramatically faster than vi(1) at 300 baud. On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: > Editing /etc/inittab with ed(1). > > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS <tuhs@tuhs.org> wrote: > > > > editing /etc/inittab > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
[-- Attachment #1: Type: text/plain, Size: 801 bytes --] And, of course, even worse editing with cat! ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Thu, Jun 30, 2022 at 5:22 PM Larry McVoy <lm@mcvoy.com> wrote: > When your tty settings are messed up, ed(1) has saved my butt a number > of times. Also really pleasant to use on slow modems where just the > screen refresh takes a long time. > > ed foo.c > /^busted_function > .,.+20p > > is dramatically faster than vi(1) at 300 baud. > > On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: > > Editing /etc/inittab with ed(1). > > > > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS <tuhs@tuhs.org> > wrote: > > > > > > editing /etc/inittab > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > [-- Attachment #2: Type: text/html, Size: 1629 bytes --]
I’ve just used it in a paper I’m writing. As an aside, the relatively recent ed(1) mastery book by Michael Lucas is a rather fun (and very informative read).
C
> On 30 Jun 2022, at 22:21, Larry McVoy <lm@mcvoy.com> wrote:
>
> When your tty settings are messed up, ed(1) has saved my butt a number
> of times. Also really pleasant to use on slow modems where just the
> screen refresh takes a long time.
>
> ed foo.c
> /^busted_function
> .,.+20p
>
> is dramatically faster than vi(1) at 300 baud.
>
> On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote:
>> Editing /etc/inittab with ed(1).
>>
>>> On 30 Jun 2022, at 21:43, Robert Stanford via TUHS <tuhs@tuhs.org> wrote:
>>>
>>> editing /etc/inittab
>>>
>
> --
> ---
> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
[-- Attachment #1: Type: text/plain, Size: 1080 bytes --] Loading your 18" gigantic 5 MB disc in the tray, and giving it 5 minutes to temperature equalize. On Thu, Jun 30, 2022 at 2:26 PM Marc Donner <marc.donner@gmail.com> wrote: > And, of course, even worse editing with cat! > ===== > nygeek.net > mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> > > > On Thu, Jun 30, 2022 at 5:22 PM Larry McVoy <lm@mcvoy.com> wrote: > >> When your tty settings are messed up, ed(1) has saved my butt a number >> of times. Also really pleasant to use on slow modems where just the >> screen refresh takes a long time. >> >> ed foo.c >> /^busted_function >> .,.+20p >> >> is dramatically faster than vi(1) at 300 baud. >> >> On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: >> > Editing /etc/inittab with ed(1). >> > >> > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS <tuhs@tuhs.org> >> wrote: >> > > >> > > editing /etc/inittab >> > > >> >> -- >> --- >> Larry McVoy Retired to fishing >> http://www.mcvoy.com/lm/boat >> > -- James D. (jj) Johnston Chief Scientist, Immersion Networks [-- Attachment #2: Type: text/html, Size: 2244 bytes --]
Wire wrapped computers. The Geophysics department (I worked there as a sys admin) had one and we all hated it, wanted it gone, but "there is no budget". So one night after some beers, Bruce Karsh got an evil grin, opened it up, and bent one wire back and forth until it broke under the insulation. Pulled it enough that the wires didn't touch. Attempted to boot it, nothing (which was amazing because I bet there were a ton of wires that could have been broken and you wouldn't notice until you tried to use whatever that wire did). Bruce had a satisfied grin on his face and said "They'll find budget" and they did, whatever we got was way more modern and easy to use, I think it was a Masscomp. On Thu, Jun 30, 2022 at 02:41:26PM -0700, James Johnston wrote: > Loading your 18" gigantic 5 MB disc in the tray, and giving it 5 minutes to > temperature equalize. > > On Thu, Jun 30, 2022 at 2:26 PM Marc Donner <marc.donner@gmail.com> wrote: > > > And, of course, even worse editing with cat! > > ===== > > nygeek.net > > mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> > > > > > > On Thu, Jun 30, 2022 at 5:22 PM Larry McVoy <lm@mcvoy.com> wrote: > > > >> When your tty settings are messed up, ed(1) has saved my butt a number > >> of times. Also really pleasant to use on slow modems where just the > >> screen refresh takes a long time. > >> > >> ed foo.c > >> /^busted_function > >> .,.+20p > >> > >> is dramatically faster than vi(1) at 300 baud. > >> > >> On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: > >> > Editing /etc/inittab with ed(1). > >> > > >> > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS <tuhs@tuhs.org> > >> wrote: > >> > > > >> > > editing /etc/inittab > >> > > > >> > >> -- > >> --- > >> Larry McVoy Retired to fishing > >> http://www.mcvoy.com/lm/boat > >> > > > > -- > James D. (jj) Johnston > > Chief Scientist, Immersion Networks -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
Making more mods to the mods you had already made to a driver using adb on /dev/kmem.
Using a cheap pocket AM radio as an improvised signal probe.
[-- Attachment #1: Type: text/plain, Size: 911 bytes --] Back when I worked at JPL in the late 1970s I was the most junior engineer, so my time slot on the computer (an SDS 930) was from 2AM to 4AM Monday, Wednesday, and Friday. Over time I got to know the guard who patrolled our building and we would hang out and chat when he came by and found me there with the machine room door open. After a while I was ordered to keep the computer room door closed, since keeping it open was unbalancing the A/C. Nonetheless he somehow managed to come in and find me quite regularly. One night I asked him how he knew when I was working. He told me that my program, when it was running, made a characteristic sound on his walkie-talkie. ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Thu, Jun 30, 2022 at 6:19 PM Rik Schneider <unix@deranged.schneider.org> wrote: > Using a cheap pocket AM radio as an improvised signal probe. > [-- Attachment #2: Type: text/html, Size: 2216 bytes --]
On Thu, Jun 30, 2022 at 11:14:20PM +1000, steve jenkin wrote:
> What are the 1970’s & 1980’s Computing / IT skills “our grandkids
> won’t have”?
>
[...]
Speaking any foreign language at all without help of a machine.
Perhaps also being unable to formulate one's own judgements based on
archive contained in one's own head, while offline, i.e. without
asking other people/bots what to think.
Being offline i.e. without constant buzz of b-s-hit coming in - for a
long time (define what "long" actually means - minutes, days?) and not
getting psychologically crippled as a result. Come to think about it,
for them it is like sensory deprivation is for us. The difference will
be, perhaps, that todays adult can undergo s.d. for a while and return
to normal, while I can imagine for future adult, such a cutoff (no
sensory deprivation, just internet deprivation) might result in
effects similar to post traumatic disorders (and similarly long
lasting).
Ability to turn a computer off/on. Ability to understand importance of
having the switch in devices.
Handwriting.
Ability to perform multiplication & division of long numbers on
paper, flawlessly. Already lost to youngsters, from what I hear.
Learn to use device by reading paper manual, and only this. Assuming
paper manual is any good for the purpose, not just a bunch of
slogans.
Understand minutiae of older technology, limiting their understanding
of our ways and times. So far, the gap seems to would be much bigger than
between us and, say, Homo ergaster. Perhaps the gap will be more like
between us and H. australopitecus. But paradoxically, understanding of
the world, I expect to be bigger nowadays than in a future. Even
today, how many people could explain why there is a light after
switching the light on? I recall reading about some movie, whose fans
were unable to understand why a protagonist took film (celuloid) to
some "red room". They suggested it was for making photos sharper. Now
imagine what would they say after watching Antonioni's "Blow up" where
photography making is a central part of a plot.
I am not sure - maybe I am taking it too seriously and I perceive most
of posters here as tongue in cheek. But I keep imagining that one day
some guy writes "ls -axl" and his head will be stuck on pike, because
some cretine would claim his cow's milk turned black.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
I just thought of another one. Reading maps, both road and contour maps. Google maps is a wonderful thing but they don't work in the back country. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
Sure they work. Just download the area for offline use. Bring a solar charger.
But in my day we had a topo map and a compass and liked it.
These days I would also bring a satphone or QRP ham rig.
Has anyone mentioned porting kermit to a new micro yet?
> On Jun 30, 2022, at 8:46 PM, Larry McVoy <lm@mcvoy.com> wrote:
>
> I just thought of another one. Reading maps, both road and contour maps.
> Google maps is a wonderful thing but they don't work in the back country.
> --
> ---
> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
Rik Schneider <unix@deranged.schneider.org> writes:
> Using a cheap pocket AM radio as an improvised signal probe.
A classmate and I discovered this while learning Z-80 machine language
programming on his TRS-80. Of course our programs hung all the time,
but we discovered that with a cheap transistor radio, not tuned to any
station, sitting next to the TRS-80, we could learn to follow the
execution through the BASIC code, into our machine language subroutines,
and through the various parts of those. After a while, when our
programs hung, we'd usually know just where it had happened.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
[-- Attachment #1: Type: text/plain, Size: 543 bytes --] On Thu, Jun 30, 2022 at 7:38 PM Paul Winalski <paul.winalski@gmail.com> wrote: > > o why a memory access violation is reported as "segmentation fault" or > "bus error", and the difference between the two > > o why CTRL/D is used to end a shell command line session I am not sure I know that, I'd be happy to know. > > o why CTRL/S and CTRL/Q are used for flow control in a shell command > line session > Also would be happy to know. > > o why an application memory dump after an application crash is called > a core file > > -Paul W. > [-- Attachment #2: Type: text/html, Size: 1463 bytes --]
I know something! On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: > > o why CTRL/S and CTRL/Q are used for flow control in a shell command > > line session > > > Also would be happy to know. https://en.wikipedia.org/wiki/Software_flow_control But I don't know the answer to Ctrl-D. :( And also the bus error and maybe the segmentation fault if it hasn't to do with a segment register. Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine
>> I don't know the answer to Ctrl-D. The Unix command "man ascii" has the answer: Oct Dec Hex Char Oct Dec Hex Char ------------------------------------------------------------------------ 000 0 00 NUL '\0' 100 64 40 @ 001 1 01 SOH (start of heading) 101 65 41 A 002 2 02 STX (start of text) 102 66 42 B 003 3 03 ETX (end of text) 103 67 43 C 004 4 04 EOT (end of transmission) 104 68 44 D .... Ctrl-D signifies end of transmission. Some other O/Ses have used Ctrl-Z for that purpose, presumably because Z is the final letter of numerous alphabets. There is a good book about the history of character sets (pre-Unicode) in the book described at this URL: http://www.math.utah.edu/pub/tex/bib/master.html#Mackenzie:1980:CCS Bob Bemer (1920--2004), known as Dr. ASCII to some of us, was a key person in the standardization of character sets: https://en.wikipedia.org/wiki/Bob_Bemer https://en.wikipedia.org/wiki/ASCII ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --] The joy's of problem solving (and actually problem solving). How to plugin Commodore 64's and zs spectrum to the TV. 30k dialup speeds...... Figuring out how to dialup to the internet through the banking system (maybe only in South Africa). Also figuring out how to get linux/*BSD to dialup to the internet. Coax cable networks (and the joy of figuring out that the reason why the PC is not connecting to the network is the coax cable T piece is missing. Kind Regards, Angus Robinson On Fri, Jul 1, 2022 at 3:20 PM Matthias Bruestle <m@mbsks.franken.de> wrote: > I know something! > > On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: > > > o why CTRL/S and CTRL/Q are used for flow control in a shell command > > > line session > > > > > Also would be happy to know. > > https://en.wikipedia.org/wiki/Software_flow_control > > But I don't know the answer to Ctrl-D. :( And also the bus error > and maybe the segmentation fault if it hasn't to do with a segment > register. > > Matthias > > -- > When You Find Out Your Normal Daily Lifestyle Is Called Quarantine > [-- Attachment #2: Type: text/html, Size: 1720 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1799 bytes --] Configuring a uunet node Negotiating a connection with another uunet node (Back in the mid-1980s when I wanted to connect IBM Research connect to uunet we started with friends at DEC, since their node was pretty central. Their management intervened and told us that we could connect through decvax if we called our machine 'ibm-vax' ... I rejected that. We ended up connecting through another research lab nearby.) (Some time ago I played a MMORPG where you got to name your characters. I named one IHNP4.) ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Fri, Jul 1, 2022 at 9:38 AM Angus Robinson <angus@fairhaven.za.net> wrote: > The joy's of problem solving (and actually problem solving). > How to plugin Commodore 64's and zs spectrum to the TV. > 30k dialup speeds...... Figuring out how to dialup to the internet through > the banking system (maybe only in South Africa). Also figuring out how to > get linux/*BSD to dialup to the internet. > Coax cable networks (and the joy of figuring out that the reason why the > PC is not connecting to the network is the coax cable T piece is missing. > Kind Regards, > Angus Robinson > > > On Fri, Jul 1, 2022 at 3:20 PM Matthias Bruestle <m@mbsks.franken.de> > wrote: > >> I know something! >> >> On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: >> > > o why CTRL/S and CTRL/Q are used for flow control in a shell command >> > > line session >> > > >> > Also would be happy to know. >> >> https://en.wikipedia.org/wiki/Software_flow_control >> >> But I don't know the answer to Ctrl-D. :( And also the bus error >> and maybe the segmentation fault if it hasn't to do with a segment >> register. >> >> Matthias >> >> -- >> When You Find Out Your Normal Daily Lifestyle Is Called Quarantine >> > [-- Attachment #2: Type: text/html, Size: 3397 bytes --]
On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote:
> Ctrl-D signifies end of transmission. Some other O/Ses have used
> Ctrl-Z for that purpose, presumably because Z is the final letter
> of numerous alphabets.
I thought only CP/M and its descendants did that. :o (Of course that
includes DOS and Windows)
-uso.
[-- Attachment #1: Type: text/plain, Size: 540 bytes --] On Fri, 1 Jul 2022 at 10:00, Marc Donner <marc.donner@gmail.com> wrote: > > (Back in the mid-1980s when I wanted to connect IBM Research connect to > uunet we started with friends at DEC, since their node was pretty central. > Their management intervened and told us that we could connect through > decvax if we called our machine 'ibm-vax' ... I rejected that. We ended up > connecting through another research lab nearby.) > > Was IBM Research using a VAX as their point of contact with the outside world? What was it running? -Henry [-- Attachment #2: Type: text/html, Size: 944 bytes --]
[-- Attachment #1: Type: text/plain, Size: 841 bytes --] We were not using a VAX. We were using a machine called the "RT-PC" and it ran BSD 4.3 or 4.2 (I disremember which). ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Fri, Jul 1, 2022 at 10:05 AM Henry Bent <henry.r.bent@gmail.com> wrote: > On Fri, 1 Jul 2022 at 10:00, Marc Donner <marc.donner@gmail.com> wrote: > >> >> (Back in the mid-1980s when I wanted to connect IBM Research connect to >> uunet we started with friends at DEC, since their node was pretty central. >> Their management intervened and told us that we could connect through >> decvax if we called our machine 'ibm-vax' ... I rejected that. We ended up >> connecting through another research lab nearby.) >> >> > Was IBM Research using a VAX as their point of contact with the outside > world? What was it running? > > -Henry > [-- Attachment #2: Type: text/html, Size: 1838 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --] How about rewinding a paper tape dump using the rewind button on an empty mag tape spool? Blake On Fri, Jul 1, 2022 at 8:38 AM Angus Robinson <angus@fairhaven.za.net> wrote: > The joy's of problem solving (and actually problem solving). > How to plugin Commodore 64's and zs spectrum to the TV. > 30k dialup speeds...... Figuring out how to dialup to the internet through > the banking system (maybe only in South Africa). Also figuring out how to > get linux/*BSD to dialup to the internet. > Coax cable networks (and the joy of figuring out that the reason why the > PC is not connecting to the network is the coax cable T piece is missing. > Kind Regards, > Angus Robinson > > > On Fri, Jul 1, 2022 at 3:20 PM Matthias Bruestle <m@mbsks.franken.de> > wrote: > >> I know something! >> >> On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: >> > > o why CTRL/S and CTRL/Q are used for flow control in a shell command >> > > line session >> > > >> > Also would be happy to know. >> >> https://en.wikipedia.org/wiki/Software_flow_control >> >> But I don't know the answer to Ctrl-D. :( And also the bus error >> and maybe the segmentation fault if it hasn't to do with a segment >> register. >> >> Matthias >> >> -- >> When You Find Out Your Normal Daily Lifestyle Is Called Quarantine >> > [-- Attachment #2: Type: text/html, Size: 2199 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --] On Fri, Jul 1, 2022 at 10:03 AM Steve Nickolas <usotsuki@buric.co> wrote: > On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote: > > > Ctrl-D signifies end of transmission. Some other O/Ses have used > > Ctrl-Z for that purpose, presumably because Z is the final letter > > of numerous alphabets. > > I thought only CP/M and its descendants did that. :o (Of course that > includes DOS and Windows) > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS used ^Z as an EOF character in their text file format. The key is that they stored a block count, not a byte count in the META. Thus the last byte needs a marker to tell the OS to stop reading. [Early DEC OS's may have done that also, but I never looked at their FS formats]. Unix, of course, never made any distinction to the core OS WRT to 'type' [other than Regular/Directory/Special] and Ken stored a character count. So there was no need to signal EOF with a markered stored on disk.. A pipe or the shell on the other hand does have a need to signal the end of a transaction, and 'End of Transmission,' as Nelson points out, is the ASCII character reserved for the same. ᐧ [-- Attachment #2: Type: text/html, Size: 2677 bytes --]
Steve Nickolas wrote:
> Nelson H. F. Beebe wrote:
>> Some other O/Ses have used Ctrl-Z for that purpose, presumably
>> because Z is the final letter of numerous alphabets.
>
> I thought only CP/M and its descendants did that.
Also TOPS-10. And proably other DEC operating systems, but I don't know
much about those. I believe CP/M was inspired by many of the DEC
traditions,
[-- Attachment #1: Type: text/plain, Size: 669 bytes --] On Fri, Jul 1, 2022 at 9:50 AM Lars Brinkhoff <lars@nocrew.org> wrote: > Steve Nickolas wrote: > > Nelson H. F. Beebe wrote: > >> Some other O/Ses have used Ctrl-Z for that purpose, presumably > >> because Z is the final letter of numerous alphabets. > > > > I thought only CP/M and its descendants did that. > > Also TOPS-10. And proably other DEC operating systems, but I don't know > much about those. I believe CP/M was inspired by many of the DEC > traditions, > VMS, TOPS-20, RT-11 and RSTS/e did as well. Presumably RSX did too since DEC tried hard to keep RSX/VMS 'finger compatible' though I have no first hand experience with RSX to say for sure. Warner [-- Attachment #2: Type: text/html, Size: 1110 bytes --]
[-- Attachment #1: Type: text/plain, Size: 552 bytes --] On Fri, Jul 1, 2022 at 11:50 AM Lars Brinkhoff <lars@nocrew.org> wrote: > I believe CP/M was inspired by many of the DEC traditions, > If you do some Internet searching, there is an interview (IIRC from Byte Magazine in the late 1970s) where its author (Gary Kildall) straight out said he was trying to emulate RT-11 for an 8080. The funny thing to remember is that Kildall was a language guy, he wrote CP/M to demo his programming language PL/M for Intel. The demo ended up having more longevity than the tool he was trying to sell. ᐧ [-- Attachment #2: Type: text/html, Size: 1563 bytes --]
Tomasz Rola [01/07/2022 02.41]:
I recall reading about some movie, whose fans
> were unable to understand why a protagonist took film (celuloid) to
> some "red room". They suggested it was for making photos sharper.
Except that we didn't use red light in our darkrooms at all, at least
not from the 1970s and on. Panchromatic film, of course, needs to be
developed in total darkness, so we used film tanks.
Photographic paper was not sensitive to red light, but neither very
sensitive to yellow-green or amber brown light, which we used when
developing paper copies.
--
Hilsen Harald
Слава Україні!
[-- Attachment #1: Type: text/plain, Size: 655 bytes --] On Fri, Jul 1, 2022 at 12:22 PM Warner Losh <imp@bsdimp.com> wrote: > since DEC tried hard to keep RSX/VMS 'finger compatible' though I have no > first hand > experience with RSX to say for sure. > Hrrmpt... maybe/sort of/after a fashion ... as a UNIX guy and someone that lived it (much less an ex-DECie), I famously argued with Cutler that he didn't! [It's a good beer story for some time in person, but not really for TUHS other than to say it happened, and it was a VMS *vs*. UNIX debate between DC and myself one night at the old Maui Kai in Littleton, MA with our old common boss rsg (*a.k.a.* Fossil) acting as the referee] ᐧ [-- Attachment #2: Type: text/html, Size: 1825 bytes --]
On Fri, 1 Jul 2022, Lars Brinkhoff wrote:
> Steve Nickolas wrote:
>> Nelson H. F. Beebe wrote:
>>> Some other O/Ses have used Ctrl-Z for that purpose, presumably
>>> because Z is the final letter of numerous alphabets.
>>
>> I thought only CP/M and its descendants did that.
>
> Also TOPS-10. And proably other DEC operating systems, but I don't know
> much about those. I believe CP/M was inspired by many of the DEC
> traditions,
Yeah. As, independent of its position as a knockoff CP/M, was the
original MS-DOS (2.0 brought in a few things from Xenix).
-uso.
Early use of ASCII control characters was ALL over the map. I remember typing in a BASIC program to approximate PI during a college tour in the late 70's, and whatever system they had (maybe Univac?? there was an unplugged RCA Spectra in the hallway) required typing Control C (ASCII ETX) instead of RETurn on the teletype. *THAT* was a mind-f*ck! Clem Cole wrote: > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS > used ^Z as an EOF character in their text file format. The key is that > they stored a block count, not a byte count in the META. Thus the last > byte needs a marker to tell the OS to stop reading. [Early DEC OS's may > have done that also, but I never looked at their FS formats]. I TEND to think of the DEC ASCII traditions as coming out of the PDP-6 Monitor (later TOPS-10), which probably dates to c. 1964, and modern Unix/Linux systems are almost fully infected with DEC conventions (DELETE, CTRL/U, CTRL/C vs @/#/DELETE for example), except for ^M and ^Z. The earliest version I have on hand is version 3.19, which includes PDP-10 (KA10) support (c.1968). The scheduler (CLKCSS) has Tom Hastings name on it, dated 6 SEP 67. Tom wrote the MIT CTSS (timesharing on IBM 709/7090) scheduler, and the DEC T/S system mirrors CTSS in many ways (project/programmer numbers). CTSS used ASCII, and it would be interesting to know what conventions were used there!! On topic: Ken might know. @/# seem to have been used on Multics. The full duplex terminal code (SCNSRF) with Robert Clemmens name on it, dated "27 NOV 68" has the following conventions: Use of "^Q" as a convention for control characters. CR ^M return to column zero (used alone in files for overstrike) LF ^J line feed: line terminator HT ^I horizontal tab VT ^K vertical tab (n line feeds on a TTY) FF ^L form feed XON ^Q start TTY paper tape reader XOFF ^S sent by TTY PTR on end of tape? ^U clear input line ^Z EOF 0177 DEL delete a character 033,0175,0176 "ALTMODE" -- used in DDT (& TECO), echoes as "$" I don't have a set of Commonly Used System Programs (CUSPs) from that era, so I can't see how they handle ^Z if they see it in a file. I don't remember seeing ^Z in disk files on TOPS-10. A quick look at the 3.19 code (I rescued it from six DECtapes while at DEC; three each for full & half duplex versions of the code!) and didn't spot the on disk/DECtape metadata formats, but I suspect they were just block counts. There ARE files I've pulled off of tape with embedded NULs, so I suspect code was written to ignore NULs whereever they appeared. "Dump Mode" I/O, where you passed IOWDs -COUNT and WORD_POINTER in halfwords, rather than transferring character at a time into a buffer, was a way to speed up disk I/O, which would easily result in multiple embedded NULs. My recall is that we thought of disk files as made up of blocks, and not characters. MIT AI's Incompatible Timesharing System (ITS), a dig at CTSS (and DEC as well?) used ^C instead of ^Z for EOF, appearing (in triplicate?) inside of (older) files. And ^Z stop a (sub)job and drop into DDT (the debugger *AND* command interpreter), which could be examined, continued, or killed (ALT CTRL/X). I've always assumed BSD used ^Z as the suspend character for this reason. TOPS-20 (and perhaps later day TOPS-10) had file metadata indicating file byte counts, and byte sizes (1-36 bits), but TOPS-20 ALSO only allocated file storage on a page basis (512 36-bit words instead of the TOPS-10 256W block size). The PDP-7 unix inode stores a word count, rather than a byte count, and ISTR programs ignore NULs for the same reason. > Unix, of course, never made any distinction to the core OS WRT to 'type' > [other than Regular/Directory/Special] and Ken stored a character count. > So there was no need to signal EOF with a markered stored on disk.. > > A pipe or the shell on the other hand does have a need to signal the end of > a transaction, and 'End of Transmission,' as Nelson points out, is the > ASCII character reserved for the same. I don't know the rationale for DEC's use of ^Z for EOF, but as I pointed out above, use of ASCII control characters wasn't widely standardized in the 70's (is it today?) To pull the thread back to the list topic 1. Remember which of @ and # deletes a single character. 2. Fix a filesystem without fsck. 3a. Buy a controller card to be able to use a disk 3b. Write a driver for a third party controller. 4. Edit a driver and recompile the kernel to change partition sizes. 5. Use dd to convert a mainframe tape to variable line length ASCII. 6. Wonder whether something with a serial port is a DTE or a DCE. 7. Figure out the serial port settings for a terminal/modem: data bits, parity, stop bits. 8. Adjust jumpers on a peripheral 9. Insert or remove wires for IRQ bus continuity Non-UNIX related: Punch job control cards..... Burst fanfold paper by flicking their finger, to get your printout. Spread out fanfold paper on the floor to get a "big view" .......
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --] Phil nice list. On Fri, Jul 1, 2022 at 3:23 PM Phil Budne <phil@ultimate.com> wrote: > I've always assumed BSD used ^Z as the suspend character for this reason. > Yes, Kulp's Job control for the PDP-11 was based on his ITS experience. Joy picked it up from Kulp. The other big gift to UNIX from ITS was Eric Shienbrood's more(1) command [discussed elsewhere]. This brings us back to the topic -- the need for more(1) as either built-in like ITS or as command [UNIX] is lost with today's infinite scroll buffers. > To pull the thread back to the list topic > > 2. Fix a filesystem without fsck. > Much less, what was fsck(1) original name at CMU ;-) or why tjk wrote the first version. 4. Edit a driver and recompile the kernel to change partition sizes. > Doing the same with adb(1) on the kernel binary as well as understanding disk geometry and calculating the HEAD/CYL/SEC to block numbers properly. > 6. Wonder whether something with a serial port is a DTE or a DCE. > How about knowing what DTE and DCE mean in the first place. Along with why CTS/RTS (HW) flow control was really needed at high speed. Why the UNIX community tended to migrate to aftermarket DH11, instead of DZ-11s - particularly for UUCP > 8. Adjust jumpers on a peripheral > How about having the proper jumper sizes. Or realizing the DIP switches were not actually toggling properly so the address was wrong. > 9. Insert or remove wires for IRQ bus continuity > Know what a BUS GRANT card does. ᐧ [-- Attachment #2: Type: text/html, Size: 4670 bytes --]
Clem Cole <clemc@ccc.com> writes: > On Fri, Jul 1, 2022 at 10:03 AM Steve Nickolas <usotsuki@buric.co> wrote: > >> On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote: >> >> > Ctrl-D signifies end of transmission. Some other O/Ses have used >> > Ctrl-Z for that purpose, presumably because Z is the final letter >> > of numerous alphabets. >> >> I thought only CP/M and its descendants did that. :o (Of course that >> includes DOS and Windows) >> > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS > used ^Z as an EOF character in their text file format. The key is that > they stored a block count, not a byte count in the META. Thus the last > byte needs a marker to tell the OS to stop reading. [Early DEC OS's may > have done that also, but I never looked at their FS formats]. > > Unix, of course, never made any distinction to the core OS WRT to 'type' > [other than Regular/Directory/Special] and Ken stored a character count. > So there was no need to signal EOF with a markered stored on disk.. > > A pipe or the shell on the other hand does have a need to signal the end of > a transaction, and 'End of Transmission,' as Nelson points out, is the > ASCII character reserved for the same. But that's a common misconception and not how Ctrl-D works on Unix. Ctrl-D is part of the terminal discipline and causes an immediate stop of the current read(2) syscall. If nothing is in the input buffer, this causes a zero-length read which is detected as end of file. You can verify this e.g. by typing "foo<Ctrl-D>" into cat(1). It will print "foo", but not exit. Another Ctrl-D will then quit cat(1) due to the empty read. In no case, a ASCII Ctrl-D 0x4 is sent over a pipe or to a shell. (Over the pty, yes.) cheers, -- Leah Neukirchen <leah@vuxu.org> https://leahneukirchen.org/
[-- Attachment #1: Type: text/plain, Size: 1113 bytes --] On Sat, Jul 2, 2022 at 3:36 PM Leah Neukirchen <leah@vuxu.org> wrote: > But that's a common misconception and not how Ctrl-D works on Unix. > Point taken and my bad on my explanation. Absolutely, any characters can be stored or read/written in a file. As you explained, the *interpretation* of the character is done elsewhere and my words could have been misunderstood by my lack of precision. In fact, tools like uucico and IP over serial all required a full 8-bit path without any interpretation through the terminal handler and would have needed other tricks like escaping to have been made to work otherwise. But what I did say was true. The question was why ^D and I pointed out that the ASCII EOT character was picked for the characters for the terminal handler to use when it needs to make the distinction of when this is the end of the input sequence - i.e. EOT. Moreover, we were discussing a number of chars being processed by the terminal handler such a # @ <DEL> vs. ^H ^U ^C or SW flow control ^S/^Q, Job Control ^Z/^T and the like. mei cupla for not being more clear. ᐧ [-- Attachment #2: Type: text/html, Size: 2585 bytes --]
[-- Attachment #1: Type: text/plain, Size: 752 bytes --] Thanks for asking Ori, I was just working up the courage to express my ignorance On July 1, 2022 6:05:30 AM PDT, Ori Idan <ori@heliconbooks.com> wrote: >On Thu, Jun 30, 2022 at 7:38 PM Paul Winalski <paul.winalski@gmail.com> >wrote: > >> >> o why a memory access violation is reported as "segmentation fault" or >> "bus error", and the difference between the two >> >> o why CTRL/D is used to end a shell command line session > >I am not sure I know that, I'd be happy to know. > >> > > >> o why CTRL/S and CTRL/Q are used for flow control in a shell command >> line session >> >Also would be happy to know. > > >> >> o why an application memory dump after an application crash is called >> a core file >> >> -Paul W. >> [-- Attachment #2: Type: text/html, Size: 1830 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1261 bytes --] On Sat, Jul 2, 2022 at 7:02 PM Mark Sutton <mes@lazo.ca> wrote: > /2 6:05:30 AM PDT, Ori Idan <ori@heliconbooks.com> wrote: > >> >> On Thu, Jun 30, 2022 at 7:38 PM Paul Winalski <paul.winalski@gmail.com> >> wrote: >> >>> \ >> >> >>> o why CTRL/S and CTRL/Q are used for flow control in a shell command >>> line session >>> >> Also would be happy to know. >> > ASCII reserved four characters, ^Q through ^T, for unspecified device controls. The ASR 33 Teletype, which had a built-in paper tape reader and punch, allowed programmatic control of these devices using these characters: ^Q started the reader (assuming paper tape was in it) and ^S stopped it. In classic Teletype use, the protocol was bidirectional. (By the same token, ^R started the punch, which meant that characters sent to the terminal were punched as well as printed, and ^T stopped it. Some DEC OSes used ^T to print a single-line status of the current process. I do not know why ^C (end of text, as opposed to ^D which is end of transmission) took on its present role, but it was definitely already true in early DEC OSes. > >> >>> >>> o why an application memory dump after an application crash is called >>> a core file >>> >> See https://en.wikipedia.org/wiki/Magnetic-core_memory [-- Attachment #2: Type: text/html, Size: 3592 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3070 bytes --] But that's a common misconception and not how Ctrl-D works on Unix. Ctrl-D is part of the terminal discipline and causes an immediate stop of the current read(2) syscall. If nothing is in the input buffer, this causes a zero-length read which is detected as end of file. I once read a Patricia Cornwell novel in which the plot hinged around some crooked person typing cat > ttya Somebody is coming meaning to send a message to /dev/ttya, but instead, creating a file named "ttya". (I almost surely have the details wrong, but I'm too lazy to go searching for the real quote, which isn't relevant here.) Cornwell said the ttya file was of size 18, so, being an obsessive nit-picker, I sent her a letter saying that it could have been 18 bytes long, but that would imply that the sender terminated the message with CTRL-D rather than a newline and then terminating the command, the latter of which seemed much more plausible for a novice user. Rather than ignoring my letter, or telling me where to shove my letter, she sent me a gracious thank you note, and an FBI hat, which I still own. On Sat, Jul 2, 2022 at 3:37 PM Leah Neukirchen <leah@vuxu.org> wrote: > Clem Cole <clemc@ccc.com> writes: > > > On Fri, Jul 1, 2022 at 10:03 AM Steve Nickolas <usotsuki@buric.co> > wrote: > > > >> On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote: > >> > >> > Ctrl-D signifies end of transmission. Some other O/Ses have used > >> > Ctrl-Z for that purpose, presumably because Z is the final letter > >> > of numerous alphabets. > >> > >> I thought only CP/M and its descendants did that. :o (Of course that > >> includes DOS and Windows) > >> > > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS > > used ^Z as an EOF character in their text file format. The key is that > > they stored a block count, not a byte count in the META. Thus the last > > byte needs a marker to tell the OS to stop reading. [Early DEC OS's may > > have done that also, but I never looked at their FS formats]. > > > > Unix, of course, never made any distinction to the core OS WRT to 'type' > > [other than Regular/Directory/Special] and Ken stored a character count. > > So there was no need to signal EOF with a markered stored on disk.. > > > > A pipe or the shell on the other hand does have a need to signal the end > of > > a transaction, and 'End of Transmission,' as Nelson points out, is the > > ASCII character reserved for the same. > > But that's a common misconception and not how Ctrl-D works on Unix. > Ctrl-D is part of the terminal discipline and causes an immediate stop > of the current read(2) syscall. If nothing is in the input buffer, > this causes a zero-length read which is detected as end of file. > > You can verify this e.g. by typing "foo<Ctrl-D>" into cat(1). It will > print "foo", but not exit. Another Ctrl-D will then quit cat(1) due > to the empty read. > > In no case, a ASCII Ctrl-D 0x4 is sent over a pipe or to a shell. > (Over the pty, yes.) > > cheers, > -- > Leah Neukirchen <leah@vuxu.org> https://leahneukirchen.org/ > [-- Attachment #2: Type: text/html, Size: 4982 bytes --]
On Fri, 1 Jul 2022, Matthias Bruestle wrote:
> Date: Fri, 1 Jul 2022 08:17:32
> From: Matthias Bruestle <m@mbsks.franken.de>
> To: TUHS <tuhs@tuhs.org>
> Subject: [TUHS] Re: "9 skills our grandkids won't have" - Is this a TUHS
> topic?
>
> I know something!
>
> On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote:
>>> o why CTRL/S and CTRL/Q are used for flow control in a shell command
>>> line session
>>>
>> Also would be happy to know.
>
> https://en.wikipedia.org/wiki/Software_flow_control
>
> But I don't know the answer to Ctrl-D. :( And also the bus error
> and maybe the segmentation fault if it hasn't to do with a segment
> register.
^D = ASCII EOT
ASCII trick, check the ascii(7) manpage, look at the octal set. For any
CTRL-<letter>, drop the high bit and look at that entry.
D -> 104
EOT -> 004 (End of Transmission)
S -> 123
DC3 -> 024 (Teletypes used this as XOFF)
Q -> 121
DC1 -> 021 (Teletypes used this as XON)
No one asked about these, but my favorites:
@ -> 100
NUL -> 000
[ -> 133
esc -> 033 (ASCII esc)
--
Michael Parson
Pflugerville, TX