I'd argue that none of those are technology companies. We call too many companies that use computers technology companies.

Sure they use or even develop software but it's for their own internal uses. They do not develop technology as an end product to sell. They sell a service.

The semicon industry (Intel in particular) has a program that they enforce with vendors to give validity to that story about the chip plant. They call it "Copy Exact!" (the exclamation mark _is_ part of the name)
They would rather simply hold everyone in the supply-chain accountable for any trivial change in process or material rather than characterize exactly every part of their process and test all of those parameters every time input product or equipment is received. I get the point of it, but at some point you are virally enforcing the supply chain all the way back to mother nature where the raw materials came from. Or there are some variations in process that fly under the radar like weather or phases of the moon during production.
I literally have to take training every year because one of our customers happens to be a supplier for this industry.

There's probably a reason Roku's hardware price is a fraction of Apple TV...

You don't need the drivel they are dispensing. Read a book, take up a hobby. Get some DVDs from the thrift store.

That's exactly what people are suggesting.
Until the day the lawyers bugger off (which is never), the blame will be pointed at the manufacturer. Whoever attempts to fix that machine off-the-books is going to deny anything or not be known to the case at all and unless you have forensic evidence of their involvement, then it will look like a 'product defect' or 'improper training' of the previous time it was serviced. Both of which blame the company. Maybe there could be super-secret "void" seals or something clever that a non-trained person would not be aware of, that would be helpful to showing that a non-trained person tried to fix it.
When the manufacturer lands in court, at least they can say they tried to prevent the situation. It probably isn't very expensive to file copyright infringement cases, so that is cheap insurance.

False choice. I want a healthcare system with mandates to have the capacity in place to avoid the whole problem in the first place. No, I don't want people touching a machine unless they are factory-certified, including FDA-approval of that training program.

Because I don't read the title of every comment. So when somebody does this, I'm reading a partial sentence thinking: WTF, is my brain broken or is this person just really bad at English? oh, wait, no they are just doing that thing again... that wasted my time and now I don't care what they were saying, moving on. It seems like some type of clickbait, except probably not that great since the titles are largely ignored.

All performance comparisons aside, what are peoples' feelings about Intel Management Engine vs. whatever AMD's equivalent (or lack of)?
I'm personally leaning away from Intel on that issue alone.

C is minimal, predictable, etc. But I think swillden's comment is related to the fact that getting optimal code (predictably) is hard due to the fact that the language lacks enough constraints to allow the programmer to convey enough clues to the compiler/optimizer, so it typically builds for the worst-case. Maybe it should be stated that "...so the compiler and optimizer have to try and read the programmer's mind to figure out the _most optimal way_ to keep the code safe." And I'm not talking about things like forcing "register", or even "inline". I work on projects with C at a low-level. The resources I work with still force me to write asm routines if I can't write my C code in a way that reduces the range of possibilities that the compiler needs to consider.
You can do a lot with 'const', creating small areas of scope for local variables, or even just re-ordering operations that are not dependent on each other, etc. But eventually you find areas that the language doesn't help with, or the specific compiler implementation took shortcuts. Function calls tend to be very rigid in their assumptions about register allocation. One function call in the middle of a stretch of code can force the compiler to generate a lot of register and stack juggling. If the compiler is good and the function can be inlined, maybe it can prune out the code a bit. But I'd put that in the "unpredictable" category depending on a lot of factors.
Also, a giant hole in optimizing C is when you need to handle custom number types or create custom math operations. In that regard, it is not 'portable assembler'; it would be nice if it was. Generally, you will have to write your own asm to access the ALU flags and do the most efficient thing. Compilers tend to just cast numbers up to the next biggest type that is big enough, then call a pre-written routine. That can have an exponentially larger effect on the number of cycles and memory needed. Maybe this isn't as important on 32-bit or 64-bit processors in garden-variety applications, but this is a big deal for doing signal processing on 8-bit and 16-bit ones.

I support police and the thankless job they have to perform. What I don't understand when I see documentaries on television (not fiction) is that a lot of police departments require this "get to the ground" policy of taking people into custody.

I'll rant: Many situations end up in a pile of officers shouting conflicting orders, trying to force the suspect to do anatomically impossible maneuvers with his face down in a pile of hazardous street trash full of used condoms and needles, to someone who is probably hard-of-hearing, autistic, or just intoxicated. I'll grant that minimal risk to the officers is an important factor, but is that outcome achieved? I'll also acknowledge that some of the suspects will intentionally dramatize any approach.

That being said, I would value your perspective on this: Is there (or was there) good evidence to support that the "forcing the suspect to the ground" approach is justified in all the ways it can go badly and/or takes into account various peoples' limitations? Are there newer "schools of thought" in the industry?

exactly! I'm pretty sure cops already assume this, I'm not sure why this is still a thing to require the orange tip on toy guns. Real guns are sold or modified in all sorts of candy-colors these days if you want that option.

I, too, am one of the overly annoyed. Came here to find this argument. Overly used jargon does have negative consequences. It doesn't communicate what you specifically want it to, shuts the greater audience out of the conversation. And, quite frankly, takes more effort to educate everyone on the terminology, which ends up being endless disagreement anyway. 'Unpatched security flaw' is just as easy to say as "Zero-day hack" and carries a lot less presumptions that may or may not be true. Whether the vendor did or didn't know about the flaw is murky at best. Whether it was disclosed or not is a separate and orthogonal binary question. Whether a patch and/or mitigation exists is yet another point of data (and probably the most relevant to users.) If your goal is to chastise vendors, then maybe you care about the other points.

Other terms that overly-annoy me:
- White paper
- using 'ask' ask a noun
- using 'spend' as a noun
- incorrectly applying 'point-blank'

I can see it both ways too: it's fairly naive to think that uninstalling would clean-up everything like subscriptions, security settings, etc. Too many other experiences with technology would indicate this. i.e. does an uninstaller on a PC ever _really_ remove all traces of the application? And most things that we "sign-up" for like an email account, etc. also have web access regardless of the computer or phone used to create the account.

On the other hand, for an audience of mainstream users or even technical users who simply lack the specific familiarity and are assuming the apple store is a walled-garden, they should not need to have any technical experience or security knowledge to get the most reasonable outcome. For example, when I was new to Smartphones, I didn't really understand that certain permissions like OAUTH work on a global scale beyond the phone itself and that those vectors still exist after removing an app that had asked for those permissions. (Whether or not an exploit exists, it gave me chills when I realized that I had several unused instances of that still active that could hypothetically allow one service to communicate with another without me _actually_ authorizing what is going on.) I didn't even know OAUTH existed; the smartphone ecosystem simply allows apps to ask the user for it without explanation of the ramifications.

Being subscribed to a service that you decided not to use or didn't even access after the trial period is without reason; it boils down to: "ha ha, you should have known better, I'm keeping your money now."

The companion to this type of fleecing is when it is made nearly impossible to unsubscribe when the user does remember to do so... I was briefly considering XM/Sirius radio subscription (I was drawn in by the introductory rate and figured "why not"), but then a little voice told me to check how the unsubscribe works on their website... Guess what, you cannot unsubscribe at all via the website (but of course you can begin a subscription via the website.) A quick search of the web indicates that calling their service line results in nothing but tears and grief, very hard to finally get a subscription to end.

It seems at the moment the FAA thinks anything above ground level is "airspace." Don't jump-up in the air, lest you become an unregistered aircraft.
Do I need FAA approval to put up a swingset? At what point does the obvious and practical situation prevail (surrounding trees, terrain, etc.)
 

Sure you can update the phone, but the phone won't keep user data unless it's been unlocked.

The only avenue of updating and keeping the user data is to unlock the phone then update. Apple has purposely made it so that there isn't a backdoor.