Technically true. However in the quest for low latency there has been a tendency for some to colocate with the exchange. So if an exchange system and a broker system are in the same high physical security room and have a direct connection between them then the risk is mitigated to a degree.

I am a former Apple II and C64 programmer. Back in the day I was hired to port a PC game to the Apple II. The game was written in C and it's project manager told me the good news, such-and-such company just released a C compiler for the Apple II, that would make my port easy. Despite my youth I was able to maintain a straight face, accept his check, and fired up the LISA assembler once he left.

In more recent years, late 90s, I did some tuning of PowerPC based Mac games. I had the chance to go to Apple to have them help with the performance tuning. I was thrilled at the opportunity since I had just written my first PowerPC assembly code and wanted some more experienced people to give it review. One of the Apple engineers was a MrC (one of the better PowerPC C compilers at the time) evangelist and he basically was off to the side getting more and more pissed off that the compiler couldn't beat the few functions a newbie (with respect to PowerPC, I did have a ton of experience with 6502, 68K and x86 16- and 32-bit) wrote in assembly. He spent most of my visit fiddling with the compiler. Fortunately the other two Apple engineers were much more helpful.

Drones have cameras that are superior to the Mk1 Eyeball. Plus the remote human operator (loosely the "pilot") receiving the camera feed has 2 Mk 1. Drones may navigate autonomously but it takes a human to make it shoot.

I was referring to the era of PowerPC based Macs and the motivation for Apple's ultimate switch to Intel. Plus the PowerPC is something a little different than the workstation class POWER cpus from IBM.

You are assuming a game that was designed to be cross platform. In reality many of the games ported to PowerPC Macs were designed and written only for x86 Windows by their development team and porting to the Mac was done by a different team when the game is near completion or has already shipped.

Perhaps, but they fail at it. Game developers often **have to** make up for the deficiencies of compilers.

Perhaps the average programmer, but those specializing in assembly language routinely beat the compilers. Assembly is merely less common today because of (1) cost and (2) CPUs are so overpowered for nearly all tasks we can live with less efficient compiler generated code.

They ran Warcraft, Starcraft, Diablo and World of Warcraft.

Wrong on two counts. Cutler had worked on VMS but he did not bring it with him. NT was written from scratch. Also, he was not brought on board to rewrite Windows, he was brought on board to rewrite OS/2. While IBM worked on 32-bit x86-specific OS/2 2, Microsoft would in parallel work on the CPU architecture portable OS/2 3, aka "NT OS/2". Microsoft and IBM "broke up" and NT OS/2 was renamed Windows NT.

No. The goal was twice the performance at half the price of the x86.

Now Intel's CISC based x86 was certainly more difficult to work with in terms of improving performance but Intel was not exactly lacking in resources, human or financial. Even if it took 10x to improves CISC compared to RISC, Intel had the 10x. Intel pulled off friggin miracles with x86 performance, not one expected them to reach the clock rates they did.

It turned out that in general PowerPC had a 20% performance advantage over an x86 at the same clock rate, getting twice as fast was only achieved in very specialized circumstances. However Intel was able to achieve higher clock rates than PowerPC and maintain a general performance lead.

Stop thinking in terms of employees, that's the point of this exercise, the email addresses on the distribution list can include functional roles. company_web_site_manager@sony.com, senior_web_admins@sony.com, etc. Basically the slots in the corporate org chart come with an email address based on the function so you don't necessarily have to know who the person in that role is nowadays.

So your calendar server has a list of people rather than your email server, that's not much of a difference.

Actually you might want to re-think who is having the woosh moment. :-) I never said it fixed the problem. I offered a practice that is an improvement, i.e. forwarding and multiple recipients, that reduces the opportunity for unread emails.

That's why I wrote person or persons. Plus when someone is told they are now responsible for or involved in domain registration they go update the recipient list for the email address. There is no need to update some outsider's records. There is no need to get into the former employee's email. It really is an improvement over using employee emails directly.

Not quite, it should be a special purpose email like domain_registration@sony.com rather than an employee email. However the special purpose email should forward to those responsible, involved or overseeing the particular thing. The special purpose email should not be something that someone is supposed to log in to.

This is why you don't directly use employee email addresses for certain business activities. These activities get their own emails which forward to whoever the responsible person or persons are. Ex. domain_registration@sony.com. Note "forward to", these would not be standalone email addresses that someone has to log in to.

Those shiny new autos are also full of PowerPC chips. :-)