Graduates who can do more than a rote recitation of OSI layers? I spent a good part of my career writing network servers and I suspect a good number of my colleagues had never heard of the OSI layers, let alone been able to list them (which I myself can't do off the top of my head) -- it's just not that important at the application level. In a high school class, there are a lot more general computing topics that should be covered and diving too deep into certain areas, as Osugi Sakae notes, adversely impacts the more useful coverage.

I guess it depends on the dates, but was that true? I was an undergraduate programmer working for a professor at the University of Maryland in 1980 or 1981 when the CS graduate student computer lab installed their first VAX. It ran UNIX, of course (BSD, I guess, though I don't think I was aware of the distinction at the time). The lab already had a raised floor and air conditioning as the existing PDP-11s were decidedly not physically small.

Yes, DEC became "old codgers" unfortunately. I would have liked to have seen an OS combining the best of VMS and UNIX, but that was not to be.

At least one person still does! When I moved from VMS to UNIX 35 years ago, I wrote a shell script to create versioned backups of a file. I wrote another script to invoke my editor after creating a new backup version of the file to be edited, so FILE.TXT.001, FILE.TX.002, ... It has saved my life too on occasion. (My 35-year-old editor is MicroEMACS programmed to work like keypad EDT.)

You don't think DEC engineers understood "autosave"? Probably not, because it wasn't needed -- Vaxes never crashed! I even remember a system operator removing the disk pack I was editing a file on in order to move a large set of files to another computer. I left the EDT editor up. She brought the disk pack back a couple of hours later and EDT resumed where I left off.

This was in the early 1980s. Keep in mind the state of UNIX. In the late 1980s, prior to his Tcl/Tk efforts, John Osterhout researched log-structured (i.e., journaling) file systems because his department's UNIX workstations crashed frequently and reboots took forever. Recovering using the LFS significantly reduced the reboot times.

Any Y2K problem on VMS would have been in the applications software, not the operating system. VMS represented time with a 64-bit, 100-nanosecond count since an epoch in 1858. So it's not subject to the 2038 problem either. But, yes, updating the applications software may not have been worth the effort and I can understand a company switching to another OS and/or vendor.

With some work, not much typing actually! :) I had some experience with UNIX when I graduated from college and went to work on VMS in real life. As AC notes, you could define aliases for commands and I did so for ls, rm, etc., etc. I wrote a DCL script for cd that would convert the command, "cd subdir" to VMS's "SET DEFAULT [.subdir]". Also, as AC notes, you could define logical names which function much like environment variables. I added a "d" argument to "cd" to indicate a logical name, so "cd somewhere d" was the equivalent of UNIX's "cd $somewhere".

AC notes the abbreviations for command-line qualifiers, but, like you, I think that UNIX-like command-line options are preferable to VMS's and everyone else's /-qualifiers. VMS programs can be written to use command-line options and I did so in later years, but, unfortunately, in order for a program to scan its command line, the program must be defined as a foreign command in DCL. Easily done in one's login file, but an annoying requirement.

As I recall, indexed files were simply binary files that contained a key-to-location-within-file table. I came to work on an image processing ground system in 1982. "Work orders" were used to identify intervals and scenes of data to process. A work order was stored in a file and as the order was processed, programs would update status and quality fields in the interval and scene records. In addition, a program had to be written to allow hand editing of the work orders. This always seemed to me to be excessively complicated. When we reused the software in the mid-1980s for a commercial project, it was wisely decided to switch to plain-text files for the work orders.

(I don't remember if DCL scripts could access indexed files. And possibly indexed files were more efficient on the 4-MB, 1-MIPS Vaxen in 1982.)

Yes, the lock manager! In the early 1990s, we built a two-VAX ground control system for an experimental radar instrument flown on the Space Shuttle and we used the distributed lock manager to initiate automatic fail-over to the redundant computer.

We ported a UNIX+C generic control center software system (from NASA) to VMS for this. (A project for the Italian Space Agency who specified VAX/VMS.) I had helped to write that UNIX software plus I had extensive VMS experience, so I was brought on as a subcontractor. The port was surprisingly easy as DEC provided a thorough C library including BSD networking. One program used fork(), but I worked around this by pre-spawning processes. I had already written higher-level calls for SysV IPC (message queues, semaphores, and shared memory), so it was a simple matter to adapt them for VMS. (I used mailboxes for simple counting semaphores. Also, VMS followed an "everything is a file" philosophy and mailboxes were integrated into the I/O system unlike UNIX message queues - that's a humorous jab at UNIX in case you don't get it!)

DEC's X Windows used VMS event flags instead of socket file descriptors for the X Toolkit add-input mechanism. This was easily handled by posting an asynchronous peek on a socket and having its trap, when invoked, set an event flag. Oh, did I forget to mention that VMS had had a robust, consistent, industrial-strength, asynchronous I/O system (for both files and arbitrary hardware) since before I began working on VMS in 1982?

I did encounter one odd performance annoyance (i.e., not seriously impactful). The select() system call was showing up higher than expected in performance runs using DEC's gprof equivalent. In stepping through select() with the debugger, I found that select() was using floating-point arithmetic to access bits in the bit masks! I reported that to a DEC employee on the USENET comp.os.vms newsgroup and he passed it on to the appropriate department.

... telcos were traditionally government-owned ...

Which companies and when?

Government bureaucrats are no different than corporate bureaucrats. I'll trade my wife's hours-long calls to our private insurance company for your DMV visits any day of the week.

I don't remember it, but it sounds like South Korea simply made the same type of choice that private companies were making all over the US and the world at that time: use IE6. And, regrettably, IE6 had a long life as a result. My employer at the time used a commercial electronic timekeeping system that also relied on an IE6 plug-in. I was one of 3 or 4 people that used Linux in the company, so I bought a copy of CrossOver (?) to run IE6 under Linux just so I could fill out my timesheet. (Yes, my machine was dual-boot, but the mandated, performance-crippling antivirus software on our company's Windows installations made it impossible to briefly boot into Windows.)

The "spectacular failure" of id.me will probably be a massive breach that leaks the data for 100s of millions of people. Like the credit reporting companies, the private id.me can hide it or minimize the impact, ultimately avoiding any responsibility. The federal and state governments could theoretically switch vendors, but doing so would be a massive undertaking and headache.

Not to question your memory, but the "IBM 8080 machine" sounds more like an Intel development system. In 1977, a friend took my brother and me to his office at NASA's GSFC, where he designed 8080-based experiments which flew on high-altitude balloons (with $200-at-the-time military-hardened 8080 chips). He had an Intel 8080 development system, all blue boxes. In 1984, I worked on a project using an Intel 8086 development system, again all big blue boxes and 8" floppies. (We were using 80286 processors running in 8086 mode.)

Does anyone know if IBM ever produced an 8080 computer? The original IBM PC appears to have been 8088-based (an 8086 with an external 8-bit data bus).

https://en.wikipedia.org/wiki/...

... fondly remembering the days when a PC was any personal computer and not just an IBM PC or its derivatives ... :(

even at 1200 baud

I remember, in 1995, a new employee telling me I was crazy for having gotten a 1200-baud modem for my Commodore 64, his reason being that nobody can type faster than a 300-baud modem can handle. Ahh, BBSs and QuantumLink, my memory of the former being of dialing an obsolete number and having the guy on the other end cursing about getting all these crank calls (I could hear him because the Commodore modems had a speaker), and my memory of the latter being that it was nerve-wrackingly slow (perhaps because of its semi-graphical UI)!

Unrelated to DOS, but back in the mid-1980s, we used iRMX-86 on 80286 single-board computers in 8086 real mode. Our computers were going out to lunch when returning from an interrupt service routine. Our local Intel representative had never heard any similar complaints and we even got an official Intel 80286 hardware emulator in-house to try and debug the problem. We finally had a conference call with some Intel engineers and they told us, oh yeah, there's a bug in the return-from-interrupt instruction (all interrupts were briefly enabled before the prior interrupt mask was restored from the stack) and they gave us an RTI macro to get around the problem. Then, a couple months later, Jerry Pournelle mentioned the bug in his BYTE column! Aarrgghh! A lot of wasted time and effort--and Pournelle knows all about it!

If I were a democrat, I would vote for Bernie Sanders on moral principal. Hillary is simply nonsensical.

Am I missing something, or is it fair to say that if you were a Democrat, you would know how to spell?

Doesn't anyone read Slashdot? manishs, who made this post, posted the same story, with the same links, on June 15: Intel x86s Hide Another CPU That Can Take Over Your Machine -- You Can't Audit it.

Back in the 1990s, on the comp.lang.c or comp.os.unix USENET news group, there was a knowledgeable poster who also was a COBOL evangelist. He once posted a 4-line, portable COBOL program that sorted a file. (All those divisions people make fun of are optional in COBOL..) Let me repeat: 4 lines to sort a file and portable to any system that has a COBOL compiler. You can't do that in C; remember that system("sort ...") (or even "sort" from a command line) is not portable. Of course, COBOL has a standard, internal SORT function. As with any language, COBOL is useful in the appropriate circumstances.