> DEC's view of the language to use was Basic!. This was at a time just prior to c appearing and it was believed that Fortran was not the language of the future.
This isn't quite what happened. BASIC could be easily implemented in a few KB of assembler on a 8-bit/12-bit/16-bit computer. C could not. Fortran neither. Prior to the 32-bit/VAX generation compilers had to be split into several binaries - one per pass, or overlays depending on the OS, making their use painful and slow and not an option on the lower end systems. BASIC meanwhile worked just fine on those low end machines.
That comment about how easy it is to trash a file system on those old unices...
My first boss would look over our shoulders to make sure we ran sync before reboot but in an idiosyncratic way that I had forgotten about until now. The mantra was:
# sync
# sync
# sync
# reboot
When she did it it was always typed quickly. The Pyramid we had did have some file system issues although we continued to do it on our Sun systems as well.
Not sure why she asked us to do it three times. Was a habit for quite a few years.
It was explained to me back in the stone age that one did 3 syncs because disks were slow enough that if you did one sync all the buffers might not be flushed before the reboot took hold. So do 3 syncs to make sure. Borking a filesystem wasn't fun.
Not saying it's correct, and it's still a habit for me.
"One sync tells the system to flush all i/o buffers, the second one serves to ensure the buffers are sync'ed, and the third is useful in case slow-quitting processes meanwhile even still have things to flush before letting go of a node, and then of course .. ;reboot .. "
Yeah, but it also means, if done in rapid succession (i.e. one shell cmd "sync;sync;sync", it can tell the machine on the other end of the i/o to do 'special' operations, such as rewind tape, settle card tray intake, etc.
Long-forgotten aspects of operation which neverless fit in the 'class' of action, where data is settled and made safe.
Its not quite accurate or good folklore though, because it misses the fact that "sync;sync;sync" is distinct from "sync <enter> sync <enter> sync <enter>" and the reason for that is that the machines (tape and otherwise) on the other end would interpret such fast contiguous syncs (as opposed to the human RNG) as instructions to, for example, rewind the tape .. or shuffle the card tray .. peripherals and resources which, alas, have fallen from our consciousnesses ..
Bastard operator, checking in. Cut my teeth on paper, then tape, then disk.
$ sync;sync;sync # three syncs in rapid succession is interpreted by the tape machine as a rewind command .. on card tray, shuffles cards to settle
$ sync # one sync, just syncs to tape at current stream position
> The de facto emulator for most old computers is Simh https://github.com/simh/simh. The size and complexity of the individual machine apps is such that a direct port to a memory limited system is not feasible.
> DEC's view of the language to use was Basic!. This was at a time just prior to c appearing and it was believed that Fortran was not the language of the future.
This isn't quite what happened. BASIC could be easily implemented in a few KB of assembler on a 8-bit/12-bit/16-bit computer. C could not. Fortran neither. Prior to the 32-bit/VAX generation compilers had to be split into several binaries - one per pass, or overlays depending on the OS, making their use painful and slow and not an option on the lower end systems. BASIC meanwhile worked just fine on those low end machines.
That comment about how easy it is to trash a file system on those old unices...
My first boss would look over our shoulders to make sure we ran sync before reboot but in an idiosyncratic way that I had forgotten about until now. The mantra was:
# sync
# sync
# sync
# reboot
When she did it it was always typed quickly. The Pyramid we had did have some file system issues although we continued to do it on our Sun systems as well.
Not sure why she asked us to do it three times. Was a habit for quite a few years.
I found a bit of folklore on that https://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSyn...
It was explained to me back in the stone age that one did 3 syncs because disks were slow enough that if you did one sync all the buffers might not be flushed before the reboot took hold. So do 3 syncs to make sure. Borking a filesystem wasn't fun.
Not saying it's correct, and it's still a habit for me.
"One sync tells the system to flush all i/o buffers, the second one serves to ensure the buffers are sync'ed, and the third is useful in case slow-quitting processes meanwhile even still have things to flush before letting go of a node, and then of course .. ;reboot .. "
Yeah, but it also means, if done in rapid succession (i.e. one shell cmd "sync;sync;sync", it can tell the machine on the other end of the i/o to do 'special' operations, such as rewind tape, settle card tray intake, etc.
Long-forgotten aspects of operation which neverless fit in the 'class' of action, where data is settled and made safe.
Its not quite accurate or good folklore though, because it misses the fact that "sync;sync;sync" is distinct from "sync <enter> sync <enter> sync <enter>" and the reason for that is that the machines (tape and otherwise) on the other end would interpret such fast contiguous syncs (as opposed to the human RNG) as instructions to, for example, rewind the tape .. or shuffle the card tray .. peripherals and resources which, alas, have fallen from our consciousnesses ..
That is awesome. I don't think it was ever explained properly back then, so you finding this is fantastic to me. Cheers!
Bastard operator, checking in. Cut my teeth on paper, then tape, then disk.
we always used sync;sync;sync followed by a reboot command
In case anyone was wondering:
> The de facto emulator for most old computers is Simh https://github.com/simh/simh. The size and complexity of the individual machine apps is such that a direct port to a memory limited system is not feasible.
The Pico is powerful enough to run Doom.
https://www.raspberrypi.com/news/doom-comes-to-raspberry-pi-...