wux

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.

Apple has confirmed to the media that as of December 2022 that they are not pursuing on-device CSAM scanning:

https://www.theverge.com/2022/12/9/23500838/apple-csam-plans...

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):

https://www.tomsguide.com/how-to/how-to-remove-image-backgro...

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.

Contra (preposition): 1: AGAINST — used chiefly in the phrase pro and contra 2: in opposition or contrast to

(Source: https://www.merriam-webster.com/dictionary/contra)

Wirecutter: https://www.nytimes.com/wirecutter/

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.”

https://www.cochranelibrary.com/cdsr/doi/10.1002/14651858.CD...

A similar conclusion regarding lack of evidence is discussed in NIH treatment guidelines:

https://www.covid19treatmentguidelines.nih.gov/therapies/ant...

In line with consensus in the field, ivermectin is not contained among the treatment guidelines of any institution at which I have practiced.

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!

It may just be jargon specific to the Swift community:

https://www.google.com/search?q=swift+evolution+%22currency+...

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.

Before 1931, the so-called Imperial Parliament had the power to legislate for Canada, and any legislation they passed had supremacy over colonial legislation under the Colonial Laws Validity Act, 1865.

Between 1931 and 1982, the UK Parliament had the power to legislate for Canada only with the request and consent of the Canadian government. This arrangement was codified in the Statute of Westminster 1931.

In 1982, on the request and consent of the Canadian government, the UK Parliament removed its own power to legislate for Canada by passing the Canada Act 1982 (UK), which enacted the Constitution Act, 1982.

Canada remains a constitutional monarchy. The monarch of Canada is constitutionally required to be the same physical person as the monarch of the United Kingdom, but they are distinct legal persons (as is the monarch of each province).

Actually, according to comments on one of the Bugzilla reports about this issue (#1424977), the original bug implementing the feature is:

https://bugzilla.mozilla.org/show_bug.cgi?id=1423003

As you'll see, this bug is marked as private (at least as of writing this comment). So, as a matter of fact, it does not appear that even the most diligent user had the option of reviewing what's going on. So far, it has not even been disclosed who among the Firefox peers signed off on this change; that information appears to be private as well.

There are some misconceptions to be tackled here:

The key phrase being "that meets the modern standard of care", as opposed to most current available knowledge. Aka "good enough".

This is a gross mischaracterization of what it means to provide the standard of care.

And just as there's no realistic way for doctors to stay completely current (I doubt specialists in a field have trouble staying current there), I'd have to see some pretty extraordinary proof to get me to believe doctors are confirmed to be comprehensively up to date on all "modern standard of care" medical knowledge.

Each physician has their scope of practice. Outside of their scope of practice, they are expected to refer to or consult another professional. Within their scope of practice, they are absolutely required to be up-to-date in their knowledge. This includes the obligation to recognize when a patient's needs exceed their scope of practice.

And in Canada, you take what little medical care you get and you like it.

More medical care is not better medical care. A number of pioneering efforts to use resources wisely first developed in Canada are now internationally recognized. They represent impactful advances in improving the quality of care. See, for example, the Ottawa Ankle Rules.

Luckily, the vast majority of patients are utterly uninformed, so this theory would rarely be put to the test.

Contrary to your assertions, the majority of my patients ask pertinent questions and participate meaningfully in their own care. This has been the case regardless of their level of education and general health literacy.

Wow. So, you literally can't even believe a scenario can possibly exist where any patient might be aware of studies related to a particular ailment, and that upon informing the doctor of it's existence, the doctor could then go read the study for him/herself and incorporate the knowledge into their practice?

Feel free to recommend studies for your doctor's reading list. There's no reason your doctor should be averse to that--it's no different from recommending a novel. However, if delivering appropriate care to you requires the reading of studies the existence of which your doctor is not even aware, then your doctor is no more qualified to provide that care after reading one or even a small number of studies. Have no expectation that your treatment will change after recommending a paper any more than it might after recommending a novel.

It may be your "ethical and legal responsibility", but how is a doctor that sees patients 8 hours a day supposed to keep up with new discoveries, and how is the perfectly reasonable scenario of not knowing you don't know something supposed to be resolved for the good of the patient?

Continuing medical education is now a requirement of continued licensure. All doctors are legally responsible for keeping up with new developments and offering treatment that meets the modern standard of care. If I am unwilling to use some of the other sixteen hours of the day to brush up (in the unlikely scenario that I have only eight hours a day of patient responsibilities), I am required to leave the profession.

Patients do not tolerate care that’s compromised by unknown unknowns–unless it’s truly unknown to all of medical science–and the medical and legal professions do not tolerate it either.

Let me ask you this: what are you hoping to achieve when you “try to inform” your doctor? Is it to share your personal preferences and values? Your doctor should definitely take those into account. Is it to share your experience of the illness? You’re right to expect an empathetic ear. Is it to add to your doctor’s fund of knowledge so as to change his or her assessment of your condition or the treatment that you are offered? This scenario is ethically impermissible for your doctor; it has nothing to do with ego.

From the perspective of a healthcare provider:

First, every patient has very valuable knowledge for their physician: their symptoms. There's absolutely no substitute, and as a patient you are the definitive source for that information and the undisputed expert.

Second, I do find that it's very often helpful when my patients have done some reading about their condition. It shows engagement in their care and is a great way to jumpstart the conversation. And it gives me a good idea of the level of insight into their disease and the best way to approach the patient education part of my task.

However, to be clear, it is my responsibility ethically and legally to have the expertise to treat you and to apply that expertise in making an assessment and plan. If I find that I don't have the expertise that's necessary, I should be consulting with or referring you to another medical professional who does. It's your right to have your physician's thinking explained to you and to agree or disagree with the plan, and if you think your physician is wrong, it's also your right to ask for a second opinion. However, it is never ethical for me to rely on your medical judgment in formulating a plan.

So, please don't take it the wrong way when your physician limits the amount of research he or she will hear from you. I stick to strict boundaries even with patients who are physicians themselves--even when they are significantly more senior and experienced. And when I'm the patient, I try my hardest to describe only my symptoms, confident that I will receive better care that way.

FWIW, 认为 translates to "consider" for only some values of "consider." An excessively literal character by character rendering of 认为 would be "recognize (sth.) as" (but without necessarily the excessively formal connotations of "recognition"). It'd be a suitable translation for "consider" in a sentence such as "I consider children to be brats." However, an exhortation such as "Consider the children!" would not be translated using 认为.

It's unclear where you got the impression that collective ownership of the means of production is a definition of socialism invented by the American Left. The idea originates with Marx and Engels, the latter elaborating that it is both necessary and sufficient for the elimination of social classes:

"...said Marx, what we observe historically is that only one class of persons has always owned or monopolized the means of production throughout history. This condition of ownership over the means of production is the single most fundamental fact of the materialistic theory of history since it is this that leads to the division of society into economic classes." [Morrison, Marx, Durkheim, Weber: Formations of Modern Social Thought, p. 44, paraphrasing Marx, The Germany Ideology, pp. 8-13.]

"...it was seen that all past history, with the exception of its primitive stages, was the history of class struggles; that these social classes warring with each other are always the products of the relations of production and exchange -- in a word, of the economic relations of their epoch; that therefore the economic structure of society always forms the real basis, from which, in the last analysis, the whole superstructure of legal and political institutions as well as of the religious, philosophical, and other ideas of a given historical period is to be explained." [Engels, Socialism: Utopian and Scientific, p. 72.]

"The proletariat seizes state power and to begin with transforms the means of production into state property. But it thus puts an end to itself as proletariat, it thus puts an end to all class differences and class antagonisms and thus also to the state as state." [Engels, Socialism: Utopian and Scientific, p. 93.]

tl;dr--In the analysis of Marx and Engels, ownership of the means of production is what divides economic classes; economic relations are the basis upon which are founded all social and political relations in society; in the struggle between those who own the means of production and those who do not, it is by the proletariat seizing the means of production that class differences are eliminated in society.

Unless I'm mistaken, the same resource shows Chrome 55/56/57 is also at 99%?

I'd be curious if a JavaScript guru could give a little more context about the significance of that last 1%: namely, for Safari, "enumerable properties can be shadowed by non-enumerables," and for Chrome, "Array.prototype.sort: compareFn must be function or undefined."

This looked like a pretty long list of unsupported APIs, so I decided to do some research:

- CSS motion path is not an official standard; it is implemented only in Blink (Chrome/Opera).

- CSS device adaptation is a W3C working draft. It is available prefixed in IE/Edge and Opera Mini, but is unprefixed in 0% of shipping browsers.

- Client Hints: DPR, Width, Viewport-Width is an IETF working draft implemented only in Blink (Chrome/Opera).

- inputmode is supported in 0% of shipping browsers.

- MediaRecorder API is a W3C working draft supported in Blink (Chrome/Opera) and Firefox but not IE/Edge or Safari.

- Network Information API is not an official standard; it is supported only in Chrome for Android.

(Source: caniuse.com)

I stopped going through the list at this point. At least from the top of your list, none of these features are "shipped in every other browser" and some are shipped in no browsers at all. I'm not sure how it shows that Safari is "far behind the times."

If anything, the list seems to show that Chrome implements many non-standard APIs not available elsewhere. Combined with its mindshare (if not marketshare), this suggests that Chrome--not Safari--is in some ways the new IE6.

Unfortunately, you're simply not correct. The fraction of income received by the top 1% of Canadians did not decrease from 2012 to 2013, nor did it decrease from 2010 to 2011.

Source: Statistics Canada http://www5.statcan.gc.ca/cansim/a26?lang=eng&retrLang=eng&i...