shawn-furyan

Similar story, but with 3 consecutive large capacity HGST hdds that were sold as new (SMART told a different story), switching sellers each time. Ultimately just went to Newegg.

This is what is called a non-representative sample. To say the least...

Sheesh.

Eh, what's an order of magnitude here or there or at the beginning of your chain of huge multipliers? heh.. Yeah, no wonder the result was so enormous.

So oops, I guess.

The numbers are available: 65,000 CPU years & 110 GPU years.

Assuming that the massive numbers of cores necessary don't cause any extra difficulties (seems like a stretch), we get 68,328,000,000 CPU cores to do the CPU portion in 30 minutes, and 115,632,000 GPUs to do the GPU part in 30 minutes.

Assuming 1U servers each with 2 64-core CPUs, that's at least 533,812,500 physical servers, which is at least 12,709,822 42U server racks. That would take up ~85,000,000 sqft, or 3.04 square miles.

That's just for the CPUs. You could probably fit 1GPU per server, but I assume this isn't the typical config for cloud GPUs. In any case, it could probably be done in, let's call it 4 square miles of server floor space.

Note: these are pretty conservative estimates at every step. It doesn't take into account any practicalities, like having server aisles wide enough for golf carts (because, really, 3 miles on a side is a bit of a hike on foot). Or how power is delivered. Or how to communicate all of that parallel work. Or the colossal amount of maintenance staff that would be required. Or keeping that many servers cool enough to work continuously... etc.

After you figure all that out, now you can get to the small task of figuring out how to continuously deliver 120-ish[1] gigawatts of power to those servers.

[1] 90 Watts per 64-core CPU (2 of those per server), and 180 Watts per GPU (lifted from fryguy's sibling comment). Turns out the CPU part is a lot more expensive in just about every way than the GPU part. Accordingly, you would probably adjust this so that you spend 55 minutes on the CPU and 5 on the GPU portion, or something like that.

[Edit: added the footnote, and refined my estimate of the power requirements, also clarity edits]

Ah, yes. Forgot all about time dilation effects. In my defense, it was a pretty off the cuff response. Also, I would assume they aren't meant to be literally traveling at exactly light speed, but I don't know the relevant equations to figure out how that impacts my comment. Clearly, in this area, I'm a dilettante at best.

Corrections aside, it is an interesting observation that Firefly is less outlandish with this discovery (not a criticism, Firefly is optimized for fun, not scientific plausibility). Still, assuming light speed travel, Firefly's inhabited planets are still a heck of a lot closer, since the crew doesn't seem to noticeably age between the half dozen or so star systems that they visit, and don't appear to have any kind of tech to reversibly[1] halt their metabolisms.

[1] the reversibility it the hard part. Tech for halting metabolic processes irreversibly has been around for quite some time ;)

If you're using email to communicate with humans, you are using Gmail since your counterparty is almost always using Gmail. Gmail and their ad scanning is unavoidable in practice when using email so your only real recourse is to use a different communication protocol.

Gmail is reasonably secure in situations that actually occur frequently. No other providers are. But even Gmail is optimized for adoption and monitization over security, so it's security efforts only go so far, particularly when interacting with other email providers.

Or even instead of any kind of rm command. mv is less subtle. I tend to prefer

    `mv x $(date +%Y%m%d_%s_)x`

where:

    %Y - 4 digit year
    %m - 2 digit month
    %d - 2 digit day
    _  - underscore literal
    %s - linux timestamp (seconds since epoch)

This ensures that the versions you're 'removing' will be lexically sorted from newest to oldest in a way that is easy to interpret and also works if you need to try more than once in a day.

In case it's not apparent to some, this command moves the directory (or file) called

    'x'

to something like

    '20170131_1485916040_x'

Then when you're all done (i.e. production is humming and passing tests, no need to ever rush), you can delete the timestamped version, or if space is plentiful, move the old file to an archive directory as an extra redundancy (i.e. as an extra backup, not in lieu of a more thorough backup policy).

> He addresses this line of logic

He doesn't, and it's not a line of logic, it's an interpretation of the evidence. Graham didn't even look at the evidence, and came to a conclusion that becomes very hard to support once you've had a glance at a chart of the available evidence (i.e. deep analysis isn't required to recognize that his proposed mechanism is flawed).

Also, you should really heed my 3rd note. You cannot speak effectively on income inequality without having read Picketty. It is by far the most significant treatment on the subject. It goes far beyond my simple counterpuntal analysis here to bat down a poorly thought out and completely unresearched pure logical argument. At least read a couple informed reviews of Picketty. I seem to recall FT, the Economists, Mankiew and Krugman having worthwhile, messy and conflicting thoughts after it was published. Graham just is not a useful resource on income inequality.

To address your point: Yes, Macro 101 makes it clear that trade multiplies wealth, thus wealth is non-static. The Graham argument you cite is incredibly elementary, and he is not the source to be citing on the topic. That particular question is miles more elementary than any discussion of the impacts of income inequality on macroeconomic factors. Bringing it up when talking about Income Inequality is kind of like citing a clunky explanation of Newton's 2nd law of motion in a discussion about time dilation effects of supersonic flight (which relies on non-Newtonian physics). To wit, analysis of Income inequality requires going beyond the overly simplistic macroeconomic models that have led Economists to mispredict the effects of income inequality for so long. Macro 101 is not useful here. The current evidence in the field is conter-intuitive and difficult to reconcile for expert economists.

Also, again, Graham's essay is very outdated and has, to be charitable, been surpassed by more careful and thorough resources on the topic.

This actual analysis from The Federal Reserve Bank of San Francisco, which uses long running public (easily accessible) data from the Census Bureau, the BDS report[1], suggests that income inequality hurts startup creation rather than helping it.

Note: The specific relationship that they find is that startup creation is associated with home prices. This makes sense in the US, as home prices are a good proxy for middle class wealth. Here's a quick not fully vetted interpretation of this finding: When the middle class is relatively rich, they start businesses. When it is relatively poor, they don't. The aspirational income inequality that Graham posits doesn't immediately jump out when looking at year by year new startup numbers on a graph. I'm currently analyzing these numbers, but it's pretty clear that they don't support Graham's assumptions.

Note 2: The FRBoSF analysis isn't perfect for answering this question, but at least it's a good start, unlike the pure logic approach (despite the easy availability of good longitudinal Census data on the subject) that Graham published.

Note 3: The Graham essay is an essay on income inequality that came out before the atomic bomb that Picketty dropped on the subject. It really shouldn't be dragged out now because the research landscape on the field has been completely changed since it was written.

Final Note: I know that every time the word startup is used on HN, it spurs a 'No True Scotsman' debate about what qualities invalidate a new business from the label startup. Not remotely important. The FRBoSF article notes that new businesses have faster job growth than older businesses and that's the larger subject in question. Trying to throw companies out only serves to move the conversation from fact based to conjecture based by throwing out a perfectly good source of facts relevant to the matter.

[1] http://www.census.gov/ces/dataproducts/bds/

> There are smarter ways of adding security

So you assume. Have you ever investigated credit card fraud? Perhaps there are edge cases that are more difficult than you imagine.

> Imagine if any other service provider (webmail?) disabled your account frequently to "avoid fraud".

Webmail is absolutely lousy with fraud. Webmail companies explicitly disclaim all liability... so... you kinda bolstered my point there. That is, you helped add the significant texture that companies that disclaim all fraud liability can be pretty lousy at preventing fraud.

To reiterate: The entity that accepts liability should be the entity that draws the line on what risks are acceptable.

Credit card companies are pretty unique in the types and magnitude of risk that they accept and manage. They already do quite a high wire act balancing fraud prevention against user convenience. And despite some things that seem inconvenient on the surface, they are typically still the most convenient way available, by a wide margin, to conduct most payment transactions.

So... you want no fraud liability, but don't want to be inconvenienced either?...

You could always look for a less zealous credit card provider, but generally speaking, the entity that takes the liability should be able to set the bar for risk. Otherwise you get subsidized risk taking, which has a way of getting out of hand.

You may well find that credit card companies who are not very zealous about security are merely more successful at weaseling out of the liability that their customers assume they are taking.

At the end of the day, fraud creates costs, and you can be sure that SOMEONE is paying those costs. If your credit card company doesn't seem very zealous about preventing fraud, then it's more likely that you are the one who will ultimately pay when the bill comes due.

If a 'mission that matters' is important enough to spend 3 paragraphs on, but salary only deserves a single dismissive paragraph, then why exactly do we never have enough teachers?

If people really had such a great preference for mission over compensation, then the public sector, and non-profits could be 'selective'. I mean, the public and non-profit sector usually don't even have to do bullshit PR vanity projects (cough Microsoft-Google-Facebook-Amazon-Exxon-GE-BP) to convince people that they are not evil on balance. Still, it's the massively profitable companies that have the luxury of selectivity, not the ones with the best missions.

Like so much in 'management methodology' literature, there is such a willingness in this article to prefer anything (like small ungeneralizeable psychology studies[1]) that confirm clearly absurd magical beliefs (e.g. there are easy cheap scalable alternatives to compensation for retaining employees) that it is impossible to take the advice therein remotely seriously.

[1] that are being misinterpreted, to boot

[edit: added the footnote, grammar]

There are multiple ways for firms and employees to value contributions. The 'how much can the employee command on the market' method that you outline is a commodity model of valuation, and it seems to have been a poor fit for this situation on the part of the firm, since the employee held enormous non-commodity value to the firm.

Employees aren't worth the market value of their job title on the open market. They are worth the cost of replacing their contributions to the company's bottom line plus any gap in contribution that the market is unable to replace. Often early employees (regardless of objective skill level) hold tremendous non-commodity value to fast growing companies. It is ultimately very costly behavior to think of these employees as commodities.

[late note: the bottom line oriented valuation method that I outline, can of course be negative. If we take the gp's assertions as given, then the employee in question is clearly worth more to the firm than his/her 'commodity' price on the market. But it is possible for the commodity value to be higher than the value of a given employee, even once the transactional turnover costs are taken into account. In such cases, it may be preferable to allow the employee to seek his/her fortunes elsewhere. I note this to make it clear that this sort of valuation model doesn't unduly bias the firm toward retaining low or negative producing employees. By the same token, it frees the firm to recognize value in excess of 'replacement value', as any reasonable worker productivity model should]

There are a lot of hackers who know Chinese, so it probably isn't gaining you any ground. See diceware.com for how to generate strong passwords (in many different languages). Also, use a password manager with a password generator for less sensitive accounts and so that you aren't reusing passwords.

Rather than rolling your own password system, I would recommend diceware.com for strong passwords (including master passwords) that you can memorize (I am bad at memorization, and have memorized 129 bit passwords this way, and 64 bit passwords are kind of a breeze to memorize).

For the long tail of passwords that you shouldn't be memorizing in the first place, a password manager with a good configurable password generator is invaluable. I use Lastpass (I like the breadth of it's platform support: all major consumer OSes, all major mobile OSes, extensions for all major browsers). Alternatively, lot of people recommend 1password.

Diceware has better guarantees, but the password managers are usually much more convenient[1]. I weigh these costs and benefits when choosing which way to go for a particular use case.

[1] With the significant exception of passwords that will regularly have to be typed out on mobile, since diceware passwords are much more virtual keyboard friendly than random character generated passwords. This is partly because you can typically keep the entire thing in your head, not having to reference your password manager multiple times, and partly because they don't rely on special characters for their entropy, so can be typed out on the primary keyboard without switching to numeral or special character keyboards.

I'll note that this actually makes the original point, since despite your avoidance of the game, Civ VI is estimated to have been the top grossing game on Steam in 2016. So, even in this case, the game has sold gangbusters despite lackluster* AI.

*I didn't intentionally rhyme lackluster with gangbuster. Rather these are the words that sprang initially to mind, and it's a kind of satisfyingly weird combo, so I'm leaving it in.

Source: https://galyonk.in/steam-sales-in-2016-def2a8ab15f2#.nxpnuko...

Close. I wasn't claiming that it was principled. I was claiming that it's what they stumped on in course to their leadership positions. Reversing themselves on those positions violates the narrative that they've been crafting, which probably has negative political consequences.

With the scare quotes, I was drawing a distinction between the pre-Trump Republican establishment [meaning the incumbent Republican leadership along with the ideas that they stumped on to get into that position], and Trump. Trump is very different than the pre-Trump Republican establishment, and they clearly preferred other candidates (principally, Marco Rubio).

There were clearly vast distances between the Pre-Trump Republican establishment, and the Republican electorate, and so it would make sense for the post-Trump Republican establishment to move in Trump's direction. That process is currently nascent, and the differences have, if reports are anything to go on, yet to have shaken out.

Because of the way Trump operates, and because of the populist shift of the Republican electorate, I'd expect Trump to win most of the internal battles on spending. The winds are at his back. He will probably also flip many Republicans who previously positioned themselves as staunch fiscal hawks.

I would challenge that narrative, because Trump clearly wasn't "The Party's candidate". He was a populist candidate, and populists gon spend (or at least say they are).

There still seem to be deep misgivings within his cabinet about the spending, but Trump seems to tend to get what he wants, and is quick to fire people who aren't making it happen, so...

Thanks for the extra context, and alternate interpretation. You seem like you might know this story better than the writer of the referenced article, but you and the author seem to be making contradictory causal claims. I hold to my conclusion if the author's story is taken as authoritative. If yours is more authoritative, then it sounds like your conclusion is better.

I kind of took the story as an allegory when writing my comment. The article is quite vague about the details of the situation. And for all I know, it IS programmers that write specs for this European Space Agency unmanned rocket project. But the way the story is told aligns with a more universal experience of programmers blaming specs for the failings of programs, even when they should have recognized that the program was misspecified before implementing it. I ran with that interpretation because it was illustrative of something important, but it is not particularly surprising to me that the details are being questioned. The article was never a rock solid account.

I disagree. The programmer is the expert in types, so it is the programmers duty to ensure that the possible values stored in a variable of a given type are compatible with the type selected. Particularly when it comes to these sort of critical applications.

Programmers blindly following specs put together by people who have no claim to expertise in these matters without questioning the assumptions behind the spec is the cause of all manner of disasters. And "but that's what the spec said to do" is all to common an excuse when the problem is with subtle runtime behavior issues that fall squarely in the programmer's domain of responsibility.

+1

Design is not actualization.

So the salient question becomes:

How robust are modern reactor designs to manufacturing/construction/installation/etc. errors?

Human minds are heavily tuned to spot spurious patterns. 'Spotting a pattern' is very often misleading evidence because of this bias. Generally patterns that jump out at us really fit a large spectrum of possible scenarios, including that the seeming pattern is just an illusion of randomness.

True, however, it does put SOME price on data collection, rather than leaving it in the realm of pure externality. The deterrent of cost is the benefit, not the protection itself.

On the other hand, adding a price may embolden deep pocketed organizations to 'pay to absolve' for losing data to hackers on an ad hoc basis as a cheaper alternative to strong security and limiting data collection scope. In that case, the impotence of ID theft protection hurts a lot more.

IIRC +x keeps google from returning results that exclude the x term.

e.g. "x y z" ~ "x y z" + "x y" + "y z" + "x z" + "x" + "y" + "z"

where "+x y +z" ~ "x y z" + "x z"

Still, I would imagine this isn't exactly the behavior your friend would have expected.

Heh... I'll say that these points are not surprising to me. The title (as well as the, urm, Medium) strongly suggested a Silicon Valley bubble point of view. I didn't read the article, and instead came to the comments to see if my initial expectations were wrong (in which case I may have decided to read it). It seems my expectations were in the ballpark.

Down voted. I don't think this is a constructive question. Encryption wasn't even a minor policy stance of the 4 most major parties' nominees for president.

It's not very reasonable to <strike>blame</strike> pointedly question voters for actions their candidate didn't take a stance on.

[edit], thought better of using the word 'blame'. It's not an accurate characterization, but didn't want to erase the history of having initially chosen that word either.

Professional gamblers* have something to teach everyone about managing risk.

In this case, the primacy of establishing a separate fund as your bank roll, and protecting it by not letting too much of it ride on any single bet (no matter how great the bet seems), is very appropriate to self-funding your own businesses. If you lose your bank roll, then you have to stop gambling, which is bad if you are convinced you have an edge.

*I'm not a gambler of any type, unless you count investing 401k/IRA savings in index oriented ETFs and mutual funds gambling (not an unfair position).

I'm guessing that it requires a ton more expensive staff to secure prisoners that are not constrained by cheap walls, barbed wire, bars, and watch towers.