steventhedev

Regarding the specific definition of M1, you'll have to research. I'm not a banker or an economist, I'm just remembering a macro econ course from 10 years ago. It's entirely possible that the US Federal Reserve Bank has a different definition of M1 than the People's Bank of China.

Money has always been fungible, even nonfiat money. The second you have lenders in society and allow them to back loans using deposits, they effectively create money. The ratio of loans to deposits is called the cash reserve ratio, and it's pretty heavily regulated.

As for the trust question, the answer is in your question. Swift and other interbank settlement systems are independent (or co-owner) organizations that require a massive security deposit to explicitly handle the situation where a bank says "transfer 1000 to A with account with us from account B in your bank" where the transfer wasn't backed or authorized or anything like that. It's important to note that there are both pull and push systems. ACH is an example of a system that can pull. All of this is because banks don't trust each other especially if they aren't beholden to the same regulatory authority.

Define "issued". M1 is typically checking accounts and cash. M2 is stocks and things that are easily convertible into money. The rest of the M's are defined similarly, but the exact definitions vary from person to person.

M1 is always an estimate for every country on earth because you can't just take a snapshot of every bank's ledger all at the same moment and expect all the money to be there. You lack the necessary time granularity and there's a lot of gray areas like money mid-transfer between banks (missing from one, not yet written in the other), money in a van on its way to being destroyed, money in a van from the mint to a bank, bankruptcy proceedings, etc. To work around that, central banks ask retail and commercial banks to provide monthly balance sheets to prove they are stable, and base estimates off that. The IMF/World Bank do something similar with central banks that are members.

The good news is that you can find M1 estimates easily from relatively authoritative sources[0] that are good about citing their sources.

[0]: https://fred.stlouisfed.org/series/MYAGM1CNM189N

From glancing at the code, this is an observer pattern over asyncio and unix sockets. That means you're unable to communicate outside the current machine (short of hacks like ssh socket forwarding), but adding support for tcp endpoints shouldn't be too hard.

I'd be interested to see how well this holds up under load, especially compared to other common event bus patterns.

Tesseract[0] is the classic example. There's a bunch of advice for improving your accuracy with it, like making your images larger (literally just scale it up x2 or x4).

It would be interesting to the benchmark from the article repeated with different scaling options (or other preprocessing, depending on platform).

[0]: https://github.com/tesseract-ocr/tesseract

Sounds like you need to make things easier rather than harder. They have a clear economic incentive to scrape your site and will continue to do so. Rather than spending your employees time on it, open it up as an API. If someone starts hitting it too hard, send them an email to back off.

If your only competitive advantage is your pricing, then you're in a losing game. Otherwise, you're probably better off spending your efforts on making your product/service better.

How many people have you hired with you as their direct manager? How many of those have you had to fire?

I've only had to fire one person, but it was as a part time homework checker. I've only been personally responsible for 3 FTE hires in my career (beyond CV screen). I'm not the most qualified person to talk about actual hard data points on the importance of success in the hiring/firing process.

However, I do screen CVs and I've seen several thousand of those so we can imply some data from other companies experiences. I'd say maybe 5% pop out as truly problematic people who jump jobs more than once a year. There's another 10% who have been at their current job for less than a year. The overwhelming majority of those 10% are leaving because the role isn't what they were told it would be (they are pure backend dev's being forced into a frontend role, different tech stack, QA job advertised as devops, etc). The next 60% work at each job between 2 to 4 years and leave because they got bored, or weren't allowed to grow, or they were asked to work harder than they feel they should have to. The rest leave because the business closed or similar circumstances. While some of these people may be lying about the reason they're leaving, I don't think they'd lie about the amount of time they worked somewhere.

So what makes someone a bad hire? The obvious ones you can easily filter for in your hiring process. The ones that cause the conventional wisdom of "firing is hard" are the ones who just barely scrape by, draining the team with extra training, extra work, extra bugfixes, extra "oops" moments for the longest time. They're the ones who go on a PIP and improve enough that it's difficult to justify firing them with cause. The reason "firing someone is hard" isn't because the process itself is hard. It's because the ones you need to fire, the ones you're warned against, they're just a bad fit. They take up an extra desk and shorten your runway (or budget) while providing just barely more than what they cost. It's the opportunity cost of hiring someone who's not great but not horrible. The actual cost of firing an underperfomer is 2 or 3 months salary equivalent depending on contract/jurisdiction.

So we're stuck with "a-hair-to-the-right-of-astrology" because it's really difficult to filter reliably, and an amazing worker on the right team could be "meh" on the wrong one (for him/her). It may be bullshit but at least it's bullshit the entire team believes in.

In a nutshell: they aren't.

The economics of it are that in many places in the world, it is extremely difficult to fire an employee. Getting rid of an underperformer can take time, effort, and exposes the company to liability if the termination can be construed as relating to the employee being in a protected class (e.g. can't fire someone because she's a woman). Let's assume that it's a SF startup willing to play a little fast and loose and they aren't concerned with severance packages or the legal issues. They still put time and effort into training a new engineer. That's months of work that is potentially wasted.

All of that means that companies are incredibly risk-averse when it comes to hiring, and will pass on someone who looks even slightly wrong to them. It also means that the process is inherently random as a company will pass on someone they aren't sure of _even if they would have been a good hire_ just because they aren't certain. However, this also means that a lot of companies rely on self-selection in their hiring pool. Look for people they already know, from the same backgrounds, or are willing to pass through a series of arbitrary tests.

In short, it's like democracy. It's the worst form of government, except for all the others we've tried.

The strictness is in what may be listed in the robots txt, not the User-Agent header as sent by bots. the example given in the linked draft standard[0] makes this abundantly clear that it's on the bot to understand how to interpret the corresponding lines of robots.txt.

Of course, in practice robots.txt tend to look less like [1] and more like [2].

[0]: https://tools.ietf.org/html/draft-rep-wg-topic#section-2.2.1

[1]: https://github.com/robots.txt

[2]: https://wpengine.com/robots.txt

For what it's worth, that was exactly what they did:

http://www.faculty.idc.ac.il/arik/SCWeb/vidret/index.html

Unless I missed it, it looks like they didn't control for the effects of their own survey. For all we know, taking 15 minutes to drink tea between ranking news reliability.

Google found a source[0] that says around 57%. The link here is describing a solar panel as the heat source, but the technical report I found implies it usually uses waste heat from other industrial processes.

[0]: https://www.sciencedirect.com/science/article/pii/S036031991...

It should be possible to add mouseover events to have the mouse only highlight the current character block which is more authentic as well.

Isn't this overkill to verify that you don't have any invalid states? Consider the state machine as a directed graph, reverse each edge and run DFS from the end state. if you have any vertices in the graph you didn't visit, they're dead ends. That should be more efficient than the O(n^3) way of finding eigenvectors.

whooops!

100mm with 99mm payout vs 10mm and 8.5mm payout then...

For that particular round of the game, yes.

Overall? No, unless the game is very badly designed.

The whole situation arises from rolling over the losses between rounds, which "sweetens" the pot for intelligent players. It's also a good way to inflate your numbers if you know that your game might get cut next year (e.g. it might be better to show turnover of 100mm and payouts of 90mm than turnover of 10mm and payouts of 8mm).

The executive order[0] doesn't actually call out Huawei by name. I also can't find them on the OFAC search[1], so which entities list are you referring to?

[0]: https://www.whitehouse.gov/presidential-actions/executive-or...

[1]: https://sanctionssearch.ofac.treas.gov/

Asimov wrote one like this[0], but the theme is pretty common and shows up in many science fiction stories. I only call out Asimov's version because it also has the Machine screwing up orders on purpose to remove otherwise competent people from power who don't trust it.

[0]: https://en.m.wikipedia.org/wiki/The_Evitable_Conflict

> any reasonable datacenter operation is going to detect clock skew beyond some tolerance (order of seconds)

It takes time to recognize such failures. If the clock skew is only off by a few seconds or even minutes, the impact isn't so horrible, but if the clock jumps ahead by 20 years, you've effectively prevented any writes to that key for 20 years. Even if you only consider a few days, that's long enough that it can result in lost business.

> logically nondeterministic state

timestamps should only be used to tiebreak between logically observed events. You've somehow combined a timestamp field as a tiebreaker, as client data to be stored, and as a request id. If you separate them then adjusting the timestamp as a tiebreaker (along with node and counter) will remain logically consistent.

> And it's important to zoom out and look at the actual consequences of missed writes at the application layer

Lets. You wrote a distributed data store that can lose writes under certain circumstances. If the UX impact is negligible for you, that's great. However, it may be catastrophic for another use (say storing the latest price read for a stock option). For developers to use your database, it means they need to do an impact analysis for every single use. Just wait until someone decides the API is easy enough to use that they try to put payment data in there.

> If there is clock drift between nodes, then a write W1 against some node may actually "beat" a later write W2 against another node with a slower clock, but in terms of correctness, that doesn't actually matter: the write conflict still resolves deterministically.

That sounds like a great way to produce a bad UX where a computer with clock drift doesn't successfully write. With real world clock drift, this can be on the order of years especially on older hardware with a drained button cell on the mainboard or badly implemented GPS clocks. You should also be watching the newest timestamp you got for a key in each data node, and if it receives a user (not peer) set operation, it should take the max between the timestamps. Conflict resolution between peers is unchanged, but you avoid an entire class of bugs that are near-impossible to debug and yet incredibly frustrating.

From a quick glance at the readme, it doesn't seem that you do this. If the client timestamps come from your web servers, and they're all on NTP, then it won't be too bad, and the effect will only happen for the maximum NTP offset.

EDIT: did some thinking and reread what I wrote

Notably, they didn't control for social effects by looking at female and male sibling pairs with an age difference of 10-18 months. How much of this is parents favoring the male sibling?

Impressive! For anyone looking to do something similar, but in Sublime, I can recommend the LatexTools[0] plugin, which gives similar live previews of math mode. I'd never considered embedding figures from Inkscape though.

I also decided that I wanted to keep lecture notes in LaTeX, and the best advice I have for anyone is to just practice. Start from LyX if it helps, but just make sure that you grind down the rough edges. It takes a long time, but like many skills that are worth learning, it takes lots of effort but the payoff is worth it.

[0]: https://github.com/SublimeText/LaTeXTools

Maxmind (and others probably) regularly publish lists of IP blocks mapped to the owning ASN. Basically geoip but instead of mapping to geographical regions, maps it to ASN. If you want to roll your own, you can probably start from a public route reflector and go from there.

The number 64 is arbitrary, and was chosen because of potential birthday attacks on digest algorithms. Mozilla enforce the BR sometimes in extreme ways, and we derive security and trust from that enforcement. In many cases, the BR are confusing, unclear, or ambiguous. The confusion here arose from the BR requiring 64 bits of entropy from a CSPRNG and to always be positive, and ASN.1 integer fields using signed integers, so 1 bit is lost to the sign bit.

In this specific case, they have the option to use 160 bit fields for the serial number. They chose to use the minimum required of 64, apparently out of performance concerns for embedded devices with limited memory/compute.

The CA platform (EJBCA) they use defaulted to this behavior, and from what I was able to understand[0] are in the process of pushing out an update to all their customers to resolve the issue. It is very likely that someone will start going through the CT logs and we will see many reports of insufficient entropy in cert serial numbers.

[0]: https://groups.google.com/d/msg/mozilla.dev.security.policy/...

Can the admins change this to point to the actual mailing list thread[0]?

I'm still reading through the thread, but it seems that DarkMatter have some small technical issues around issuing certifications. Specifically, the claims seem to be:

1. using 63 bits of entropy for the serial number instead of the required 64.

2. name constraints were incorrectly filled in for their intermediate certificates.

3. DarkMatter's other business units may compromise the CA internally for malicious purposes.

[0]: https://groups.google.com/forum/#!topic/mozilla.dev.security...

EDIT: more background - DarkMatter have an open request to be included in the Mozilla CA Store[1], and are currently trusted through intermediate certificates rooted with QuoVadis, who were recently acquired by DigiCert.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1427262

.corp, .home, and .lan are also reserved, just not codified into an RFC yet.

Google weren't supposed to make it generally available. From their application[0]:

> .dev will operate as a closed gTLD. It will provide Google with the opportunity to differentiate and innovate upon its Google products and services through its use of the gTLD. This will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool.

[0]: https://gtldresult.icann.org/applicationstatus/applicationde...

Amazing project! An interesting followup would be a converter script from the GTFS to the json input as a generalized format of this.

I wonder if BGP could be applied in this way to highlight "good enough" routes for public transit planning?

What are the chances this is related to the G+ phase out? The timing is a little too convenient.

> No, the subscription model has been the basis for the industry for the past 100 years.

I had always been told that the subscription price was to cover the marginal cost of printing and delivery, but the majority of revenue for most publications was from advertising, which was meant to cover the cost of creating the content, whether it be entertainment or journalistic.

That having been said, you would see many things bundled together in the past, so your newspaper subscription would get you a weekly magazine, and as you mentioned with the split between basic and premium cable packages.

Stop.

Seriously. Stop.

I'm going to go out on a limb and guess that the reason you're getting downvoted is because you're advocating something that is basically eugenics wearing modern clothing. The practice of eugenics is generally associated with Nazis. Yes, those Nazis. Not just the modern ones, but the Hitler 1920s-1945 ones who started a World War. They used "superior genetics" as a justification for many of their actions before, during, and after the war.

Don't be a Nazi. Accept that this is fresh research, that genetics may set someone out on a different path but that there are many other factors that affect their life and choices. In this study[0], there is no human research, and the definition of monogamy is limited to a single mating season. It's also looking at gene expression, which means that a gene that everyone has is either turned on or off. For reference, genes are expressed differently in various parts of your body, and is a fairly good test for various types of cancer.

[0]: https://www.pnas.org/content/early/2019/01/02/1813775116