They give away their mini cell sites now for home use.
2,407 karma · joined September 10, 2010
https://github.com/rickhull
> I don't know if HGST drives are related to the old Hitachi models at all.
FTA:
> Some of the HGST drives listed were manufactured under their previous brand, Hitachi. We’ve been asked to use the HGST name and we have honored that request.
This is the wrong question. CS isn't hardly about code. Most of our CS today is from before the 1950s.
Just you, my friend. If you recall, here is the point you were challenging:
> this is a band-aid over the fact that OSes have terrible permission separation and application isolation. If OSes were better architected from a security point of view, it would be substantially less of a problem.
Would you now concede this point?
Sure. Government bonds are defined as risk-free, for better or worse. Regulatory and capital requirements ensure healthy demand for risk-free securities, aside from any "natural" demand for government bonds.
The Fed has pushed down the yields on USG bonds to miniscule levels. Firms which used to rely on a healthy yield for such bonds now have to find that yield elsewhere. The entire point, depending on who you ask, of the Fed's activities is to push investors into riskier securities.
Institutional investors forced into searching for yield bid up Facebooks and Amazons. Simultaneously, you have the more adventurous being pushed into various forms of VC investing. Some investors are desperate for yield, like underwater pension funds, and they won't get it from USG bonds. Think about the recent news regarding pension funds getting into bed with hedge funds. Other investors are sitting on huge cash balances and simply want to put them to work. There is a lot more money sloshing around the system compared to 7 years ago, some of it merely implied by gigantic reserve balances with the Fed, and is there really any question that the run-up in asset prices over the last 5 years is an effect?
The Baroque Cycle is a massive piece of work spanning 3 volumes, comprised of 8 nominally independent books. If it seems intimidating, just try the first one and see if you're not hooked. I'd love it if there was twice as much material.
Anathem is by far my favorite. Its hooks take longer to set, but for me they set much deeper. There is a lot going on in this book, and it will truly blow your mind if you let it.
Github project moved to: https://github.com/rickhull/loremarkov
I've been meaning to make it into a proper gem and update the README. Perhaps now is the time. Check examples/ in the meantime.
I would say there is nothing wrong with strategic differences, so long as they are irregularly distributed. Regular or predictable distribution would cause strategic ruts. Also, irregular movement costs are a feature. Ancient spice trading routes and deer paths in the woods rarely follow straight lines either.
Governmental organizations, in contrast, have no incentives to adapt, and no "recycling" mechanism. Failure is emphatically not an option. Worse, bureaucracy inevitably takes on the primary mission of preserving itself.
True, in that it's very complex, and it does reward an analytical approach, which may or may not accord with one's own real life. Eve is a fantastic hobby, in that it is intellectually demanding, time consuming, skill rewarding, and an emotional investment. I can't recommend it but I'd certainly suggest it for whatever it is that ails ya.
static void call_cb(const struct take_str_block *blk) {
{
(*blk->cb)(blk, "world");
}That said, my ear canal soreness is largely due to canal deformation relating to jaw movement. Perhaps this is not an issue for sleeping. Also, foam earplugs (compared to earphones) are not uncomfortable for me.
Building everything from source "by hand" quickly runs into scaling problems, and admins start to roll their own "package databases" in order to cope. Fully-baked package management becomes the solution. The problem here is that distro packages are not the latest development snapshots (for good reasons, most often and presumably). Still, there are times where newer-than-distro-repo software is required.
The author's Pandoc case may be one of those, but I doubt it. RHEL (and CentOS) packages should never (by definition) include showstopper bugs. It's more likely that bugfixes have been backported to the older, stable version. Still, it's possible that the author is correct, and the official package does not meet requirements or is otherwise unusable.
In that case, the best path forward is to build or reuse an updated package, rather than installing from development sources "by hand", e.g. `make install`. It's likely that someone else has already had this problem and has built an updated package, which you could then install, but let's assume not.
Now we're into the wonderful world of package building. We can avoid some of the author's pain here, but mostly there is a tradeoff for having to learn and deal with the packaging pipeline. The upshot is that package building may be scripted and synched with development sources, and you are keeping the metadata inside the packaging system where it belongs and can be managed (think: future updates).
This is not a problem when the principal has an exchange seat and may execute directly. Where firms are performing multiple-exchange arbitrage, and the principal splits a large order into several for execution across multiple exchanges, there is now an opportunity for something like front-running: the arbitrage firm can detect the principal's intent from the first order to hit the first exchange, and then try to move the market profitably (against the principal) on the other exchanges before the correlated orders can execute. While somewhat analagous, this activity should not be referred to as front-running.
It's very easy and common to make the leap from EMH, a purely theoretical construct, to asserting that real world markets are perfectly efficient and must therefore behave as EMH entails. This view is mistaken, and the author merely knocks down a straw man with the Buffett counterexample. Instead, in order to use EMH in the real world, one must first judge the efficiency of the market in question.
The broadest, deepest, most active and open markets are the most efficient, which is why "the stock market" (in the US) is a favorite example and testing ground. The idea is not that it's perfectly efficient but that it's the most efficient we can access. The real question is: is it efficient enough for efficiency effects to dominate? A fair view of the evidence (i.e. not hunting for or cherry-picking counterexamples) suggests that efficiency effects do dominate.
EMH is really about the futility of systematic approaches to achieving excess returns. It was conceived (in some part) as a general refutation to systematic investment proposals. Systems could range in sophistication from always bet on black to virtual Warren Buffett. Only where the system sophistication exceeds (in some sense) the current market efficiency is it able to collect. Soon the unsophisticated have no chips, and the efficiency rises accordingly. The bar is raised, over and over, chewing up new challengers and enshrining champions.
That some real world markets are subject to EMH effects also explains the cliché about the highly paid fund manager who performs no better than a dart-throwing monkey. If you find this idea appealing yet EMH is icky, you should check your priors.
You're just looking at yourself and not the entire class of shareholders. Buybacks are positive for shareholders who want to cash out. As well, the additional demand for shares tends to boost the share price.
In a contrived example where a company is totally valued by its cash balance, you have the appearance of a wash. But if a company's worth is determined by revenues exceeding expenses (profit margins) rather than cash balances, you can boost the share price beyond e.g. $50 with the increased demand, where the share price is not a simple function of cash balance but has expected cash flows as a major component.
However, you do want to avoid "CI handcuffs", where either because CI is too brittle or because you're simply integrating too many independent projects which, in order to push a change requiring coordinating changes elsewhere, requires massively outsized developer effort in order to push things through with zero CI breakage. This is more of a problem in CI systems with binary metrics like PASS/FAIL where every change that doesn't PASS is rejected.
It's too easy to "wedge" a system like this, where project X's change can't go through without project Y being able to handle the change, and you end up introducing multiple code paths in both projects on a solely temporary basis just in order to keep CI green and happy. Rather than having a zero-tolerance CI failure policy, developers should be allowed to break CI temporarily, so long as they fix it in a timely manner (within an hour or two). Per-developer breakage metrics, to the extent they are needed, should not be in terms of breakage counts but instead breakage durations.
That is, outside of production, it's fine to break stuff and quickly fix it, so long as you don't leave it broken. The big problems are where domain-siloed developers break a zero-tolerance policy because it was necessary to relax it "temporarily", and things stay broken because the policy stays relaxed and cannot be reinstated without sirens going off. Then restoring the CI policy is blocked for everyone by the one guy who knows the AIX quirks for debootstrap or whatever.
Instead, breaking changes should be "allowed" where there is a window to fix the error and still move forward. Only when the window closes without a fix should the breaking change be rolled back (automatically). This line of thinking lends itself to formal, automated policy, but this depends first on judgment and cultural approval.
As it happens, the best CI system I'm aware of for truly distributed, multiple project integration is OpenStack's Zuul: https://github.com/openstack-infra/zuul I'm not sure if it accommodates my prescription above, but if not, they probably have a better idea.
Any one datum is questionable: How were the 728 hours tracked? Were some forms of practice excluded? Is the master designation in chess equivalent to the elite mastery the 10k rule describes? Is this measurement for an extreme talent outlier?
Neither the insufficiency argument nor the existence of outliers argument have merit against the 10k hour rule, properly understood. One number cannot possibly cover the range of fields, the range of talent, and the range of practice measurements (hour tracking, practice quality). Might this single number still be a broadly useful heuristic? I'm not sure, but this article tilts at windmills unhelpfully.