Government vs. non-Government. The laws control what the government can do because they can, well, stand you up in front of a firing squad, miss badly, and you die slowly. Or be more accurate and you die more quickly, or for lesser crimes, throw you in jail. So far non-Governmental entities (mostly) can't do that - they call it murder. Doesn't mean they don't - defective products, poisoning our planet in pursuit of money, and so on - but it is still nominally (if unenforced) illegal for that to happen.

Fairfax County, Virginia by 1976 had an HP 3000 for student use (it might have done other things, I dunno), and they put 2 or 3 ASR33s and an ADM 3 (3A) in a room in (most of) the high schools that the students could use for whatever. Yup, acoustic couplers for access, but they stayed connected from morning until they closed the schools at night most every day. We only had access to a Basic interpreter to run programs, but we could create, edit, store, and run BASIC programs, and we could print our programs off to/load from paper tape on the ASR33s. The ADM3s were cursor addressable and everybody spent time writing programs that used ASCII graphics to play games. I have fond memories of how many feet of paper tape it took to print out the star trek game program that we passed around among ourselves and modified the heck out of. That was my intro to computing, and after being bitten by that bug I made a career of it in the industry.

Arrived in my email today:

Kinda sorta. The Crays had fully segmented instructions, register reservations for both scalar and vector registers, and independent hardware for each instruction type. An instruction could take, say, 6 clock cycles to complete, but after each cycle it could launch the same instruction again with different registers as input and output - so you could have 6 ADDs in flight if you used your registers carefully. It also allowed for register reservations, so you could run an add of two registers into a third, and a multiply instruction that wanted to reference the output register of the add wouldn't launch until the data was ready in the register. For the vector instructions specifically, as soon as the first result appeared in the output vector register - each register was 64 words of 64 bits - the next vector instruction could launch and start processing the output of the previous instruction as each data element popped out. There was no on-the-fly instruction reordering and no speculative execution as we understand it today - instructions would not launch if the registers they needed were reserved. However - each instruction type had its own hardware, so you could have a scalar add, scalar multiple, scalar memory load, scalar memory store, and the vector equivalents underway all at the same time. Until you ran out of registers :-). Instruction ordering was optimized by the compiler; you could add directives in your source to give hints to the compiler but if you wrote your code using the guidelines the compiler just figured it out. Seymour Cray's design was brilliant for the time. It was a fun company to work for during the glory days.

Former Crayon here... The Cray-1 had a dedicated I/O channel for each disk and supported something that looked like striped I/O across all disks at once. The Cray-1 was definitely limited by the number of channels the chassis could hold and disks you could fit in the room :-). Later models (Cray-XMP et. al.) added a dedicated external IO processor to offload all the disks from the mainframe so you weren't burning memory bandwidth while keeping the one disk per channel architecture and it's parallel capabilities. There was also an 'SSD' you could add to most of the Cray models (yup, a pile of memory external to the main chassis that looked like a filesystem of sorts to the OS) so you didn't have to wait for all of that slowly spinning rust to get to your data when you ran out of central memory. The combination of SSD and disk parallelism led to some interesting applications involving bursty very high speed (for the time...) data inbound from external sources; the processor would dump the burst to the SSD, and between bursts write it the collected data out to the disks in parallel to post-process at it's leisure.

Uh, no. The entire system was submerged in a 'fishbowl' of sorts and you had to drain the thing to replace a module. There was plumbing and pumps to drain and refill it pretty quickly. I worked for Cray as a software guy until SGI bought us out; I worked on many of those systems. Not that we sold very many...

I get to decide what my child can read, not someone else. They can control what their children can read, just like I do; remove a book from a school library and I've lost that right. My rights don't end where the religious beliefs of others begins.

They did, finally, with the M1 Pro and above. We all seem to have forgotten the 'never buy generation 1' rule...

The Feb 1 2022 date is when SFDC requires MFA in their contracts/licenses with their customers; actual, physical enforcement in the customer environments actually starts much later. Companies that use some form of 'Single Sign On' in their corporate environment, and their SSO itself implements a flavor of MFA, can meet the requirement by extending SSO to their SFDC production orgs if they haven't done so already. It looks like one of the limitations of the SFDC setup, however, is that you can't prevent someone from not using SSO even your company wants it - a user can go the MFA app route themselves and you can only catch it after the fact. You can use the SFDC developed MFA app, or any of the other MFA apps around - Google, Microsoft, whatever, that meets the SFDC requirements.

So how do pilots maintain situational awareness so that when their autopilot disengages they can take control? I'm guessing that they are staying engaged, keeping up an instrument scan, maintaining situational awareness, and so on? I'd expect that drivers would be expected to do the same things. It is certainly what I do with my car when I have it's 'autopilot' engaged, and that active work does seem to help for me - I've aborted the autopilot early many a time when I can see it is about to make a stupid decision, and have been able to recover fairly quickly when it makes a stupid decision in a situation I've not seen it make a stupid decision in before. Not like it's going to happen with the general public, tho, and even if the car makers did get more explicit on what to do, would most people even do that?

Agreed. It was sad to be there and watch it peak so high and then fall so far.

Our early puritanical foundations (many of our early colonists were orthodox/conservative/reactionary type escaping religious repression) and laissez-faire leanings (many of our early colonists were here mostly to make their fortunes) makes for a (by modern terms) a pretty dysfunctional society.

Habeas Corpus. You can sue to force your release, but that costs you money for a lawyer you probably don't have and will only (maybe) get you released, it won't get you recompensed for your unlawful imprisonment. Maybe a federal civil rights violation for which you can get compensatory damages? Same issue - you need a lawyer you probably can't afford unless they are willing to take it on a fly. Not sure it would make it as a class action since that is so hard to prove nowadays. IANAL.

You're assuming that shareholders have a level of control over corporate operations and thereby have liability for their actions. Shareholders don't; company officers do, and the laws in most of the world explicitly require this - company officers operate their companies, not shareholders. That's why the liability shield is inn place for shareholders. In some parts of the world this company officer liability does exist and does get applied (didn't a German VW company officer get nicked by DieselGate?) but in most of the world it is very, very hard to hold them personally liable for corporate misdeeds.

(vastly simplifying)

The FDA regulations for nearly everything regulated include a large pile of rules that basically say 'write down what you say you are going to do to build thing X, figure out how to prove that you in fact built thing X the way you said you were going to do so, and then actually use your tests to prove that each individual thing X was built the way you said it was going to be built. And keep all those records until X number of years after you no longer manufacture thing X'. Those rules apply to the thing and anything you use to build the thing - each individual thing itself (from ventilator to pill and beyond), and all of the stuff (hardware, software, and wetware) you use to build or track the thing.

These regulations actually derive from the original regulations that require your drug or device to do what you say it does; it is pretty much the same pattern. Decide what the thing is going to do, decide how to prove the thing does that, and then prove it. At this level, tho, you have to continue to prove it (post market surveillance) - making sure no unexpected side effects show up in use, or that the side effects aren't appearing at more than the rate you originally expected, and so on.

You really, really do want these rules. Applied as quickly as possible, but no shortcuts. Otherwise someone dies. Potentially a lot of someones.