No, this makes sense. FaceTime has worked well in the past to encourage people to stay within the Apple ecosystem. All their friends use FaceTime, so they can't switch to an Android phone. But now, as people use more and more other videoconferencing solutions because of the pandemic, they might be more open to switching to accommodate that one friend who has an Android phone and can't join in. So here's the solution to make sure they don't switch. That one Android friend can still get in. There's no need to start experimenting with Zoom instead of FaceTime. But they still aren't going to get rid of their iPhone, because they know the experience won't be as good. It's not about attracting new customers. It's about keeping the existing customers.

What is concerning are the twice refuted efforts for RDRAND to bypass the Linux kernel pool mixing entirely, and the design decisions which intentionally make RDRAND an inscrutable black box and trivial for a VMM to intercept and modify. These are not accidents.

While there is no harm in using RDRAND to complement entropy on a system, by no measure should it be used as the sole source of entropy in a system.

I tried to mod your comment +"insightful"; alas, I'm out of points...

the stars must align for a clusterfsck this big:

1) polemic agitator in attendance, in propinquity
2) opportunistic exploitation of overheard conversation occurs, twitter shaming to ten thousand
3) polemic agitator doubles down with histrionic blog post when twitter shame draws doubts and disapproval (this would be a crime in EU)
4) overly sensitive, over reactive start-up employer over compensates with firing, leading to social media furor, fanning flames
5) classy apology asking for less nuclear resolutions ignites the firestorm, critical mass achieved
6) juvenile hordes exact retribution on employers servers, DDoS'ing to oblivion until terms met
7) capitulation to vigilantes in a sea of misunderstanding drives media to madness

"Are you really honestly claiming that, based on this one rare and isolated incident, that casinos all do good to improve their overall security by getting rid of their cameras?"

No, but the "security tools" they apply should also be considered as sources of risk in the overall risk management equation. Too often security products get a pass because, well, they're security products.

The witty worm is another favorite example of this position of privilege turned against you.

I bought a Galaxy Note, and I love it. I'm not going to put anything else in the same pocket with it anyway, so why not fully utilize that space? The screen size makes it so much more generally useful than phones I've had in the past.

Your development background will be very useful in a QA / Test Engineer role, assuming you are considering joining a technically competent organization.

I say this because many companies have an antiquated view of "testers" as low skilled keyboard jockeys able to bang keys and input fields like monkeys on ritalin. Avoid these places like the plague...

A premium QA/Test Engineer will apply development and other solid technical skills to:

- Provision test systems spanning wide varies of operating systems, network configuration, applications and settings, in short: be able to build everything you need to test the systems tasked of you.

- Obtain a deeper understanding of the system under test; able to dig into code to discern logical errors and oversights, triage down to root cause and even suggest a fix/patch.

- Integrate test automation technologies into the software process so regression and performance testing is part of a continuous integration & test lifecycle. Manual testing should only be a part of your efforts, as software systems continually expand in scope and a manual-only test process will eventually be overwhelmed by progress.

- Extend and apply third party tools, ranging from code performance analyzers to network traffic capture/replay, code coverage analysis and unit test frameworks, fuzzers and chaos monkeys, etc.

- Understand security risks and defensive coding techniques to identify deficiencies in a code base or implementation/design which introduce vulnerabilities. Catching these defects before a product goes live is very rewarding and can be exceptionally cost effective.

- Develop internal tools or customize existing software using Shell, PERL, Python, Ruby, Java, C/C++, and other languages as required or appropriate for the task at hand.

- Communicate effectively with multiple stake holders in an organization: development, product support, marketing, administration, operations. These will all be interfacing with you and the ability to tailor the technical depth and nomenclature of your written and oral communications to each of these groups is critical to being an effective QA/Test Engineer.

And many other skills and capabilities I've not listed, depending on the context of your role in the group and the domain of the organization you work for.

Many people still consider QA a less important or prestigious occupation compared to other technical professions, like software development. While the prestige may be lacking, the job satisfaction of a competent QA/Test Engineer who applies development, operations, and security analysis skills to improve a product is significant.

The many varied resources you should incorporate into your tester toolbox is too long to list here. Many sites exist devoted to QA toolsmith / test automation / security analysis roles, and you're going to want some skills and tools from all of these specialties at your disposal.

Good luck! I hope you consider the switch; the world needs more competent QA/Test Engineers.

Yes; but knowing how to programming those matter compilers, ... GOTO 10

commodity based you can at least barter with or consume; in general you are correct and we agree.

they all have trade off's. i'll take decentralized, secure (potentially anonymous) Bitcoin and fend off the hackers while others pay banking intermediaries high fees for transactions performed at their leisure, presumably with less risk.

to each their own... ;)

absolutely true!

fiat currencies are just as much a shared hallucination as bitcoin.

    at least bitcoins may provide more privacy...

SCADA systems are not designed, implemented, or operated with network and application level security concerns in mind.
  (Usually. The exceptions know who they are :)

Your compensating control is physical security to limit access to SCADA elements and programming. It costs more, but you have no sane alternative.

And before you get too cocky about that restricted air gap, consider Stuxnet turning such a strength into a weakness for exploit. At some point SCADA systems will be security conscious; that day is not today...

"... there's no way in hell you could EVER know what the entire body of law"

This is where jury nullification comes in. But they don't like that much either!