Yeah, I can see why someone might assume that the activation lock would be disabled in that scenario. But on the other hand, I can also see why someone would absolutely expect that it wouldn't be.
I might want (and have wanted) to reinstall macOS and start fresh without any intention of relinquishing or transferring ownership of the physical device. And I might want to log out of iCloud because I don't want to sync my personal stuff on that computer anymore, or because something funky is happening with how messages or photos are syncing and I just want to reset it all. I'd be pretty pissed if, six months after reconfiguring everything, someone nabbed my laptop and I discovered that activation lock had been automatically disabled for me the whole time without my explicitly doing so.
Given these mutually irreconcilable user expectations, I can see why Apple would opt for a design that favors the more cautious approach where you have to press a very specific sequence of buttons to disable the lock. Maybe I'm just selfish, but knowing a laptop I sent away couldn't be repurposed but ended up as e-waste would make me feel a little guilty, but knowing a laptop I didn't want to lose got stolen with all my stuff on it exposed to the thief would make me apoplectic with rage.
I think they've got a fair point, though, that a number of those issues with the eSIM reflect reliance on factors outside their control (for example, whether or not one's carrier has competent backend systems) where before swapping a SIM card was a physical action within their control. It's a frustrating feeling when a new technology takes something out of your hands in the name of convenience but, far from being seamless, actually introduces problems that are entirely out of your hands to fix.
Engineering the virus doesn’t mean making gain-of-function mutations. “Function” has a specific meaning and it’s not a synonym for “does anything.” Instead, in broad strokes, think of “function” as referring to biological activities that give the virus some advantage over its host.
To make a simplistic analogy (necessarily imperfect but sufficient for these purposes), consider instead a computer virus. If an antivirus company patches the binary in order to make it easier to study its behavior (for example, in order to make it more debuggable), that’s “engineering” the virus but it’s not “gain-of-function.” If the company instead patches the virus so that it can take advantage of a new 0-day exploit and spread further, that’s “gain-of-function.”
Whether gain-of-function research is capable of revealing new insight into transmissible diseases not obtainable elsewhere is a point of debate among biologists, but one can be well assured that a for-profit operation isn’t going to touch it with a ten-foot pole. Engineering the virus on the other hand, or in other words making mutations in viral components, is basically a description of “doing basic molecular biology” and is non-optional.
The sort of allegation that Pfizer is responding to is more or less the equivalent of someone recording an engineer calling themselves “hackers,” visiting “Hacker News,” then writing an exposé claiming that this proves Company X is in the business of computer crime.
The activity mentioned in the Pfizer press release that skirts closest to “gain-of-function” is actually a bit you didn’t mention at all, where they’re required by regulatory bodies to determine how the virus might resist an antiviral. Unlike computer viruses, biological ones mutate under treatment pressure. The closest analogy for a computer virus might be if it phones home and downloads a new payload to modify its behavior when it detects the presence of some antivirus software. For obvious reasons, studying how a pandemic virus would mutate in response to approved drugs is both necessary and icky, hence why Pfizer discussed its biosecurity measures. The distinction they make (rightly) between this research and a “directed evolution” or “gain-of-function” experiment, is that they’re reading out an answer to the question “Does the virus mutate when we treat with this antiviral drug, and if so, how?”, not culturing viruses iteratively in the presence of drug until they obtain an optimized treatment-resistant virus.
macOS Ventura exposes new object and scene recognition features for images, including background removal in Preview (analogous to "Copy Subject" in Photos but without requiring the use of that app):
You can also use Spotlight search with keywords such as "flower" or "cow" to find images on your local storage that have those subjects; I don't recall if that is new to macOS Ventura or has been possible for several versions of the OS.
mediaanalysisd is a daemon which has for years been responsible for, well, media analysis and would perform any network tasks required to support features such as the above when previewing an image. It would not surprise me if not all image recognition tasks are done exclusively locally, although I haven't found documentation of how much exactly is or isn't. It has long been the case for speech recognition, for example, that not all of it could be done offline (although more of it can be on Apple Silicon machines).
The only way to opt out of OS-level features that send any data to Apple at all is to opt out of using macOS; even then, as I recall, the Asahi Linux installer has to pull certain bits from Apple servers for copyright reasons.
I don’t use dictation often, but I’ve not had any issues on iOS 16 (US English, iPhone 12).
One caveat is that I’d been using the betas, so I didn’t upgrade straight from iOS 15 to 16.0 as released, but I really haven’t encountered any difficulties with dictation in any of the betas or in the final release.
The Cochrane Reviews are regarded as one of the preeminent collections of systematic reviews in medicine. They conclude that “overall, the reliable evidence available does not support the use of ivermectin for treatment or prevention of COVID‐19 outside of well‐designed randomized trials.”
You can use the 'man' command in Terminal to pull up the man page (see: https://en.wikipedia.org/wiki/Man_page) for 'powerd' (that is, by typing 'man powerd'). By doing so, you'll see that it is a "launchd managed daemon" that "manages Energy Preferences."
This report worried me, but it was timely because I was literally in the process of upgrading to macOS 11.2.3.
So, while the update was downloading, I changed my firewall settings specifically to allow built-in software to receive incoming connections, but disallow downloaded signed software. I also specifically set GarageBand to block incoming connections but not other programs among those listed.
I'm happy to report that all of these settings were maintained after updating to macOS 11.2.3 exactly as-is. I wonder if the OP is referring to a different update (none that I'm aware of recently).
There is no Privacy > Advertising > Limit Ad Tracking setting on macOS 11.2.2 or 11.2.3: there's a checkbox for "Personalized Ads," which remains turned off after the update also, just as it was before.
There’s much that can be said about Twitter’s moderation policies, but entirely orthogonal to that, this quotation should be mighty upsetting to anyone who hews to the basic tenets of American constitutionalism regardless of your political leanings.
“Who the hell elected you?” The implied statement here is that, because you (Jack) aren’t elected, you can’t decide what people read; the corollary being that, because I (Ted) am elected, I can decide what people read. This is entirely backwards! “Congress shall make no law,” says the Constitution. It’s precisely because Ted Cruz is elected that the Constitution says he cannot make laws deciding what people read. That’s the entire point of the exercise!
The term "currency type" is used here to mean a type that is commonly used.
For example, although there are a variety of range types in the Swift standard library ('Range', 'ClosedRange', 'PartialRangeFrom', 'PartialRangeUpTo', etc.), 'Range' is considered the currency type. Similarly, among string types, 'String' is considered the currency type, as opposed to 'Substring', 'StaticString', etc.
Like currency (money), the idea is that APIs in different libraries across different domains of programming will generally take values of the currency type as input and produce values of the currency type as output unless there's a good reason to use a different type.
For Swift System, the stated goal is to provide low-level currency types; if that goal is accomplished, other users of Swift can rely on these types instead of supporting multiple disparate third-party wrappers of system calls that may provide similar functionality just so that they can interoperate with other libraries.
I'm curious what your results would be with the stock Terminal. Do you have the settings that others have talked about under "Security > Privacy > Developer Tools" with Terminal.app listed? If so, and the results are better with Terminal, then it'd be interesting to see if the issue is fixed when you add iTerm2 to the list of exempted apps as well.
Last I heard, my employer (large hospital in New York) is looking to buy. If you could reach out by email, I will pass it along to the relevant people. Thanks!
It's OK to be scared. You're not alone in that. It can be helpful to have someone to talk to. Even as we're trying to keep our physical distance, know that it's OK to reach out for help. And it's also OK to step away from the news for a beat if it's causing you anxiety.
I work at one of the New York hospitals mentioned in this article. Yes, I'm scared too. [Opinions not that of my employer, etc.] But we're all still showing up every day to take care of our patients, and we'll keep doing so until we can't--and then we have backup lined up. There will be hard days, but those will be in the privacy of the hospital, away from prying eyes. New York will pull through.
The problem, of course, is that elsewhere in the chain there was in fact too much checking and too little trust. In this case, it started with not trusting the physician to enter a known dose and requiring an unnecessary conversion, which kicked off the chain of events. This was immediately followed by the problem of alarm fatigue, where practically no set of medication orders can be entered without triggering a slew of useless automated warnings.
The problem of having to deal with too many alarms is not unique to the hospital system mentioned in this article. I discovered the other day that at least one model of ventilator has an alarm that sounds when any object sits in front of the display screen. There was a stethoscope dangling in front of a corner of that screen where nothing was displayed, and an alarm went off of approximately the same urgency as one that would sound if the ventilator were about to blow a patient's lungs out. The same alarm that goes off when a patient's heart rate goes from 60 to 250 bpm sounds when the patient's heart rate goes from 99 to 101 bpm. The pharmacist who was supposed to be checking my orders for sanity once paged me out of a patient room because he couldn't find the URL for the hospital's policy on titrating a particular medication, a document issued by the pharmacy. Most people would agree that it's insane to text and drive on the highway, and yet this is essentially what's being expected of every physician in every hospital while they're making major medical decisions.
This is an interesting demonstration of a hard edge of the language. It's not because Swift holds some sort of grudge against dynamic dispatch, but rather because it's trying to reconcile some subtly incompatible design goals:
1. Adding a default implementation for a protocol requirement shouldn't stop existing types that correctly conform to that protocol from compiling. This is a reasonable user expectation and makes protocol composition a more powerful feature.
2. "Retroactive conformance" should be possible: someone should be able to conform a type they didn't write to a protocol of their own creation. It's a nifty feature that makes Swift extensions very powerful but also sometimes difficult to reason about.
3. Classes should inherit protocol conformances from their superclasses. As some of the Swift core team members have explained, this is not something that absolutely had to be the case, but it seemed sensible initially.
Points (1) and (2) preclude the language from requiring the `override` keyword for the subclass `LazyGreeter` to override a default implementation of a protocol requirement not itself overridden in the superclass `BaseGreeter`, since that would mean that (1) and/or (2) would become impossible. Getting rid of (3) would remove the surprising behavior but it is rather late in the evolution of the language to make such a large change.
The way to reason about this behavior is to consider what are intended "customization points" in the language. It isn't really covered in The Swift Programming Language, but (although not intuitive) it's a fairly teachable concept:
A separate but similar issue exists with the distinction between default implementations of protocol requirements (methods declared in both a protocol and a protocol extension) versus extension methods (methods not declared in a protocol but found in a protocol extension). The former is dynamically dispatched and is considered a customization point for conforming types, whereas the latter can only be shadowed by conforming types but is not a customization point. As described here: https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future
(The Swift standard library actually uses this concept to its advantage. For instance, the inequality operator != is not a customization point for the Equatable protocol and is implemented in an extension method, guaranteeing that !(a == b) is always equivalent to (a != b) in the generic context.)
When implementing subclasses of a third-party open class, only open methods are customization points. In that case, Swift provides compile-time checking to prohibit overriding non-open public methods. This is possible because Swift does not support "retroactive inheritance" from a superclass as it does retroactive conformance to a protocol. Also, the language allows later versions of a third-party open class to stop your existing subclasses from compiling because of a conflict between a later-added superclass method and a pre-existing method in your subclass that now lacks the `override` keyword. In other words, the compiler-enforced prohibition is possible because points (1) and (2) above were not design goals for subclassing as they were for protocol conformance.
In the case illustrated by the present article, where protocols are used in class hierarchies, a third notion of customization points arises. As demonstrated here, a protocol requirement not overridden by a base class is not a customization point for a subclass. The protocol requirement can be shadowed by the subclass but not overridden. Consistent with the design goals enumerated above, this allows for the vendor of a library protocol to provide additional default implementations at a later point without breaking user code. (But if the vendor of a conforming superclass then implements an overriding implementation, your subclass would cease to compile just as it would for any other conflict between superclass methods and subclass methods.)
Fun anecdote: Born in China, given a Chinese name, then naturalized in Canada. My name was spelled out phonetically on Canadian documents, unsurprisingly. When I return to China now, the name shown on all documents is LASTNAMEFIRSTNAME, not a single Chinese character in sight.
2300 EUR in 2014 was ~3151 USD, as you say. At today's exchange rate, 3151 USD is approximately 2710 EUR. In January 2017, 3151 USD was approximately 2993 EUR.
Apple will give themselves a cushion to prevent undesirable pricing discrepancies (or the need for frequent price adjustments) if the U.S. dollar strengthens against the euro, so a product that they sell at 3150 USD after taxes in the United States would reasonably be in the ballpark of 2800-2900 EUR in Europe given exchange rates in the last year or two. This is rather close to the parent post's stated price even without adjusting for inflation.
In July 2014, the U.S. dollar was worth around 0.73 euros; today, it is worth about 0.86 euros. In January of last year, it was worth about 0.95 euros, and Apple obviously has an incentive to account for possible short-term exchange fluctuations.
2300 / 0.73 * 0.86 = ~2710
2300 / 0.73 * 0.95 = ~2993
It would appear that currency fluctuations account for a significant portion of that price difference that you're seeing.
I might want (and have wanted) to reinstall macOS and start fresh without any intention of relinquishing or transferring ownership of the physical device. And I might want to log out of iCloud because I don't want to sync my personal stuff on that computer anymore, or because something funky is happening with how messages or photos are syncing and I just want to reset it all. I'd be pretty pissed if, six months after reconfiguring everything, someone nabbed my laptop and I discovered that activation lock had been automatically disabled for me the whole time without my explicitly doing so.
Given these mutually irreconcilable user expectations, I can see why Apple would opt for a design that favors the more cautious approach where you have to press a very specific sequence of buttons to disable the lock. Maybe I'm just selfish, but knowing a laptop I sent away couldn't be repurposed but ended up as e-waste would make me feel a little guilty, but knowing a laptop I didn't want to lose got stolen with all my stuff on it exposed to the thief would make me apoplectic with rage.