scientists as superstars

s/floppy/internet access/

At least you could duplicate the floppy yourself.

Didn't early IBM PCs have hard disk options?

The first PC I used belonged to my father, who bought it in 1981 when it first came out. It had two *160 kB* single-sided floppy drives. and a modified Selectric as a printer. Initially you had to decide whether to put your files on the OS disc or the WordStar disc. ;)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC / Hobbs ElectroOptics 
Optics, Electro-optics, Photonics, Analog Electronics 
Briarcliff Manor NY 10510 

http://electrooptical.net 
http://hobbs-eo.com

Oh, I realise not all had hard disks, but I thought there were options.

I don't remember too well, since around that time I was on PDP11s running Microsoft's operating system, and CP/M machines.

OTOH I have a 1986 fat mac which on which I learned the power of OOP via Apple's Smalltalk. The performance can charitably be described as glacial.

The Smalltalk runtime was on one floppy, the image and changes.st on another.

The PC/XT with its capacious 10 MB hard drive didn't come out till '83.

Between '78 and '81 I was mostly using UBC's Amdahl 470 V6 and then V8 machines, running the Michigan Terminal System. I really liked MTS, and the computing centre had stacks of manuals that you could take away free. I chucked them all when I went to grad school in California in

1983, but I recall them as being comprehensive and very well written.

I bought a 128K Mac in 1985 to write my thesis on. (There was a student discount.) I knew it didn't have enough memory, but having seen that Apple treated their Lisa owners very well on hardware upgrades, I took a flier despite having very little money and a kid on the way.

Then Apple decided to charge $1000 for 16 41256 DRAM chips and backed it up with strong-arm tactics against anybody with the temerity to change the chips themselves.

That was as much as I paid for the computer. I've never bought myself another Apple product.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC / Hobbs ElectroOptics 
Optics, Electro-optics, Photonics, Analog Electronics 
Briarcliff Manor NY 10510 

http://electrooptical.net 
http://hobbs-eo.com

I used to look UP from my house at ships on the Mississippi river. A lot of New Orleans is below sea level too. NOLA has levees and pumps too, which is why it's slowly sinking.

Our big adventure as kids was riding bicycles down from the top of Monkey Hill, 12 feet of sheer terror.

When I reached the Age of Reason, 32 in my case, I moved to California.

--

John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 

  Claude Bernard

It's stunning how reliable a $60 2-terabyte USB drive is now.

--

John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 

  Claude Bernard

[snip]

For the record, I have not - it's too slow to do it that way. But I do have a war story from the early 1970s:

My first job out of school was as an engineer at the Federal Communications Commission in Washington, DC. We had a Univac 1106 computer. The was in the days before Burroughs, as I recall.

One fine day, I was asked to help an much older enginer whose Fortran program was tying the 1106 up for hours. This engineer was a very methodical man. He would extensively desk-check his code, and was proud that his code always ran the first time, without error.

The program estimated signal strengths of all other radio stations as measured at the transmittinig antenna of each radio system. The propagation code required the distance from the station under consideration to all other stations, which he calculated anew for each and every station, so the scaling law was n^3, for a few thousand stations. No wonder it ground away all day.

It turns out that he was unaware that disk storage was easy in Univac Fortran, or that he could compute the distance matrix once, and reload it whenever needed. Now, his program took five or ten minutes, not 8 to 10 hours.

Joe Gwinn

On a sunny day (Fri, 14 Aug 2020 07:03:14 -0700) it happened snipped-for-privacy@highlandsniptechnology.com wrote in :

I grew up on the west edge of Amsterdam, canals everywhere, the street ended in the north at a canal. That canal went into a ship-elevator, where the little boats with vegetables from the farmers in even lower level canals were lifted to Amsterdam city level so they could bring their stuff to market. Water control is a big thing in the Netherlands, sensors everywhere, central computer. It has to be maintained at about 10 cm accuracy, if too high the crops roots will start to rot, if too low the crops will die of thirst. At about 10 we moved more south, lived about every where since then, except more south where that only hill is :-)

Now for that ticked to Mars ...

While staying with a friend in Juneau, I wrote an RTOS on paper, with a pencil, and mailed sheets back to the factory for them to enter and assemble. Someone claimed that it had one bug.

I just checked my work, like good engineers do.

For what machine, in what language, and how many lines of code?

I've done much the same, but the RTOS was usually purchased and then modified. These RTOSs were all in assembly code. The largest was

35,000 lines of SEL 32/55 (a IBM 360 clone) assembly, including the file system, if memory serves.

There was much integration and OS debugging involved. Usually the applications programmers would find the problem, and be stuck. Eventually, they world call me, and I'd go to the lab. In may cases, I could tell them what they had done wrong. In a few cases, I'd say that this smelled like an OS problem, and take over with kernel-level tools, usually with immediate success because they had handed it over to me right in the middle of the problem.

And so do we all, with varying degrees of success. I know from experience when further checking is not worthwhile, and it's time for the lab.

My favorite non-OS bug was actually in a program written in SEL 32/55 Fortran. When a certain subroutine was called, the sky fell. I debugged at the Fortran level, which did isolate the problem to the call of this specific subroutine, and then hit a wall. Dropped into the assembly-level debugger, single-stepping the assembly code generated by the Fortran compiler. Still no joy. Went back and forth, multiple times. Stuck. Then, a crazy thought... Dropped a level deeper, into the CPU microcode debugger, on the machine console, and micro-stepped through the indexed load machine instruction where the problem occurred. Bingo!

In the IBM 360 instruction set, there is no "load word" or "load double word" instruction per se. There is a general "load" instruction, the load width being determined by a field just above the operand address field in the instruction word. What was happening was that the indexed operations added the entire operand field to the index register contents, and an overflow overlaid the load-width field, changing the load width to a double, overlaying both the intended register and an adjacent register. Oops. I forget which value was incorrect, the operand or the register, but one or the other had been stomped upon, but it didn't take long to trace it back to the original cause.

The compiler had no idea that an uninvolved register had been stomped, and no amount of staring at the Fortran code was going to help.

In my whole career, I've had to resort to microcode-level debugging only this one time.

Joe Gwinn

MC6800, assembly, can't remember how many lines. It included keyboard and serial and video display drivers. I designed the hardware too.

MC6800 was a pain. You couldn't directly push the index register onto the stack.

My point was that engineers usually check their work before applying power, and programmers usually don't.

Mine was a lot smaller, a couple thousand lines maybe?

The amount of checking pretty much tracks how easy it is to change it. Code might be tested and fixes in minutes, so people just fire it up and see what happens. It might take a month or two to spin a PCB layout. An FPGA is intermediate. How about the Three Gorges Dam?

BAH Branch and Hang

SCF Stop and Catch Fire

JRA Jump to Random Address

I dunno - I can't separate the messaging from the offering. I'm fine with a C/C++ compiler so I have less than no incentive to even become remotely literate about Rust.

The Rustaceans seem obsessed with stuff my cohort ( read:old people ) learned six months into their first C project. But there may well be benefits I don't know about.

It is not-not a thing; the CVE list shows that. I am just appalled that these defects are released.

Don't take any cues from Linus Torvalds. He's why my deliverables at one gig were patch files. I've no objection to that but geez...

And C++ is Just Fine. Now. It took what, 20 years?

The reasons for "no C++ in the kernel" are quite serious, valid and worthy of our approval.

I've seen this movie before. It's yet another This Time It's Different approach.

--
Les Cargill

Precisely.

All that's old is new again :)

I will not disagree, but that's where a lot of stuff is headed. I suppose you would have been forgiven for going to the beach, or sitting in a glade in the woods listening.

There were hurricane parties in Florida in '06. Alcohol figured prominently.

Actually mightily tractable, if a bit slow these days. It depends on what level of resources your adversary is prepared to deploy against you.

I had to get a security cert last year; of course I whinged and moaned but it's been one of the better uses of my time in the last 20 years.

--
Les Cargill

I'm not 100% sure what you mean by that but it's way less than important. We all know that x86 is microcoded. So was the HP3000.

One of the greatest reads in tech is McDyson-Spohn, "ATM Theory and Applications". They go all Michener and start with the volcanoes that create that island.

In this text, they prove the theory of "eternal return" w.r.t communications technology. The wheel in the sky, all that.

That was in the before times. But yo better believe I have my own data available 100%. I even test restores.

--
Les Cargill

Real men didn't have flo... oh bugger it :)

These are the good old days.

--
Les Cargill

Never mind the bandwidth of a NVME M.2 SSD. It's several orders of magnitude faster than the interface to a nice graphics card.

Higher order USB standards are in a horse race with that. It's an embarrassment of riches.

--
Les Cargill

There either aren't any or we whistle past the graveyard of them.

The great calculating machine of the economy is beating is at software.

To our benefit.

--
Les Cargill

Too many people /think/ they know C.

I first used C in ~81, and learned it from the two available books, which I still have. The second book was, of course, a book on traditional mistakes in C "The C Puzzle Book".

It is horrifying that Boehm thought it worth writing this

and that it surprised many C practitioners.

Rust directly addresses some of the pain points.

If you think C and C++ languages and implementations are fault-free, I'd like to visit your planet sometime :)

You can start with the C++ FQA

Watching (from a distance) the deliberations of the C/C++ committees in the early 90s was enlightening, in a bad way. One simple debate (which lasted years) was whether is ought to be possible or impossible to "cast away constness". There are good reasons for both, and they cannot be reconciled. (Yes: to allow debuggers and similar tools to inspect memory. No: to enable safe aggressive optimisations)

Worse: 30 years!

I first used it in '88, and thought it a regression over other available languages.

Oh, we've all seen too many examples of that, in hardware and software! The trick is recognising which bring worthwhile practical and novel capabilities to the party. Most don't, a very few do.

The jury is out w.r.t. Rust and Go, but they are worth watching.

Java is, C# isn't.

During installation C# assemblies are compiled into code optimised for the specific processor. Of course those optimisations can only be based on what the compiler/installer guesses the code will do at runtime.

I've wondered (without conclusion) whether that is why it takes so long to install Windows updates, compared with Linux updates.

Caveat: I haven't followed C# since the designer (Anders Hejlsberg) gave us a lecture at HPLabs, just as C# was being released.

None of us were impressed, correctly regarding it as a proprietary me-too Java knockoff with slightly different implementation choices.