I don't think this is all that strange, because even within the English language there's a difference of interpretation of what the "first floor" really is. British English uses "ground floor" for the floor that is at ground height and "first floor" for the first floor you need to reach by stairs. American English often interprets "first floor" as the first floor entered (the one on the ground). Of course, the British rule has left the American continent these days, but in other countries this could very easily become a problem.
In a country with different cultures, languages and systems of writing it's only natural that the Chinese representation reflects what a Chinese person would call that floor, with the English representation next to it converted to whatever level of language compatibility someone might choose for international mail.
It's strange in that my floor number changes depending on what language you are using. For systems that parse addresses into a structured format it's a real problem, as they need to ensure they are rendered into the original language.
A China Unicom customer service representative told AFP that the December 1 “portrait matching” requirement means customers registering for a new phone number may have to record themselves turning their head and blinking.
Reading it closely, though, the evidence on the face-scanning point seems weak. The source is a customer service representative who said may. That's two weak points: a customer service representative is not who you'd normally ask about policy, and "may" also means "may not". Also, that's the only thing that particular source is quoted about.
I'm not sure what to do, because there doesn't seem to be anything unambiguous in the English-language press. All the articles I've looked are reporting on the same directive that was issued in Sept and took effect Dec 1. So I guess we'll quote the directive in the title above. If anyone can suggest a more accurate title we can change it again.
I love jupytext, but i feel like it’s a patch on a problem that should have just been solved. Just change jupyter to work directly in the genereres file format and skip the “pair files” hassle.
adding git tooling for a specific file type seems like a slippery slope, no? (assuming you are saying that git itself should have this tooling built in - if you mean some sort of addon, fair enough but then everyone who uses jupyter & git needs to install that addon)
I am not suggesting that git itself should ship with a bunch of custom merge utilities for specific file types. git ships with a mechanism that allows custom merge drivers. Setting up custom merge drivers might not be ergonomic right now, but it could have some benefits compared to the transformation approach. For example merge conflicts could result in a valid notebook and it could be manually resolved inside the notebook interface, no need to dive into the text file.
Jupytext works as an extension in Jupyter. Your work is saved as py automatically whenever you work on the notebook. So it's not a conversion at commit time, unlike say nbstripout
“The boys” in this context are a managers cronies, not any random person who happens to be male. In fact the phrase excludes men too, who don’t play golf or whatever.
More to the point, if you fold corporate income tax into VAT then maybe you pay more for iPhones, but then you pay less for all domestic products (assuming the total tax revenue remains the same), and so the primary consequence is only removing the relative disadvantage for domestic companies.
We use downdetector.com because status pages tend to take up to an hour or so to update, if they ever do.
reply
jgrahamc 4 days ago [-]
1042 UTC First alert of global traffic problem 1057 UTC Internal group chat room up and running 1102 UTC Status page updated
So, first alert to status page was 20 minutes.”””
In those 20m we had repeatedly checked your status page, realised it was our issue and started pulling engineers to deal with it as per procedure. People are on call, it's highly disruptive.
Surely you knew within those 20m that something was up?
In the end we realised it wasn't our issue because we checked Twitter.
Yep. I tend to agree that we could have gone faster. The difficulty is that getting clear information out fast when you are dealing with a difficult situation is hard.
But, I guess we could have put some status up quicker.
I'm irritated, however, that you picked on Cloudflare as a bad actor here when we strive to be transparent and quick to get out full information whereas others (e.g. Amazon) are slow as mud.
But I get that being on the other side of this is difficult when you don't have information.
Amazon, Google, seem far far worse. I wasn't intending for my post to me representative, just that the CF outage is recent and affects me more personally than the others atm. Also, I had zero expectation my comment would actually be read, this is quite a surprise.
If it's any incentive, if the status page had any inkling that something was wrong, I'd be first on here posting "omg their status page is real".
Fair enough. Thanks for making the comment. Made me think about how fast we act in terms of public status pages. And sorry that route leak affected you.
For example, 2/F in English may be 三楼 (third floor) in Chinese.