I'm more of a desktop user, but I wasn't happy with what was out there so I made my own (but only for Melbourne): https://davidjohnstone.net/weather/melbourne . I'm tempted to turn it into a proper Australia-wide product. The BoM's data licensing fees (in the order of $5k/year) are a bit of a barrier.
Yeah, the network effect is strong, but there's never been a better time to challenge it. I think the potential of success is partly based on quality of the alternative, but also on the direction Twitter goes from here. It doesn't seem like the worst bet to make.
It seems its decentralised nature is a hindrance to some or many potential users[1]. My impression is that it's often treated as an alternative, but not really a truly viable alternative, and the field is wide open for something better.
Thanks, that's interesting. Yurou Zhong, in her book Chinese Grammatology, traces the end of the latinisation movement to a precise date in 1958 when Zhou Enlai gave a speech "当前文字改革的任务" ("The Current Tasks of the Script Reform"), where he announced the current tasks are to simplify characters, promote putonghua and issue and implement a pinyin plan, conspicuously not including further alphabetisation.
The comparison between Latin in Europe in the early modern period and literary Chinese in the Sinosphere for much of history is pretty good (and often made). Latin and literary Chinese are very different languages, but had similar roles in society by being the standard written language in a world where everybody spoke different languages (that were heavily influenced by, or even derived from, but different to the written form).
> This is only because the plan for simplified characters died midway through. There was a second round of simplifications that would have gone even further with talks of full phoneticization if that succeeded.
I was under the impression that most of the debates about moving from Chinese characters to alphabetic writing happened in the pre-PRC period. For example, Lu Xun supported Latinxua Sin Wenz[1] in the 30s. These proposals failed for a variety of reasons. Simplified characters were introduced in the 50s. Pinyin was also introduced in the 50s, but unlike previous latinisations meant to replace the Chinese characters, it was only ever intended as a teaching tool. I think there was still a thought to replace Chinese characters with alphabetic writing at a later stage, but, in practice, it pretty much died in the 40s.
The New York Times' article on her life has a couple of corrections for things that look like they were written earlier and not updated with the latest when published. For example:
> The earlier version misstated at one point the length of Queen Elizabeth’s reign. It was seven decades, not “almost seven decades.”
I wondered the same. The main downside is that you need to do some processing to extract the entries from the dump and get the plain text of the fields you want.
I'm also a little surprised they didn't think Wiktionary was sufficient for languages apart from English. I could be wrong, but my impression is that it's pretty good for major languages[1].
You're right about the numbers often being expressed in W/kg, because power to weight is more important than power when going uphill. For big climbs (more than half an hour or so), that number is closer to 6W/kg for the best, or maybe a little more (especially if you go back in time a bit for some reason…).
To improve compression of a sorted list of words you can replace the (initial) letters repeated from the word above with spaces before compression and add them back as an extra step after decompression. For example, if the previous word was "apple", the next entry will be " y" ("apply", edit: HN removes extra spaces, so this should be four spaces + "y") ("apple" will probably already be entered as " le" (three spaces + "le")). In theory a compression algorithm could handle this automatically, but in practice this gives better compression.
This is conceptually similar to what OP does by storing the (numerical) difference between the words. Also, if you have a list of numbers that aren't random, they generally compress better if you turn it into a list of the differences between the numbers.
A simple compression algorithm (miniLZO is apparently 6KB compiled) might be small enough and save enough bytes with compression to make it worth it for OP.
My understanding is that all numbers in the dump correspond with Facebook accounts, so this shouldn't be the reason.
Another option would be that someone else has that number listed for their account. Has Facebook always required confirmation that a number is valid? I saw one my friends' numbers in the data except the account had a different name.
I don't think that helps, because the address space of numbers is too small so anything is reversible. My solution to this was to generate 99 extra random numbers that start with the same digits as the real one and send them all to the server. The front-end then shows just the result the user cares about but the back-end doesn't know which is which.
I don't know what there is to do other than to be aware that the combination of your name and number (and maybe some other details) are not private, so there's no reason to trust anyone just because they know those things.
As far as seeing what was leaked, you could find the data yourself (but I'm uncomfortable giving instruction on how to get it). It would be nice if it was possible to extend the tool to be able to send the information for a number to the number (because that's the only way I can think of that demonstrates ownership of the data) but that can't be done for free and it therefore seems too complicated to set up.