skysight-inc/HackerNews huggingface dataset:
>They are incredibly slow and energy inefficient;

Human brains are energy inefficient? Well, thats a first ;)

"In 1990, the legendary Caltech engineer Carver Mead correctly predicted that our present-day computers would use ten million times more energy for a single instruction than the brain uses for a synaptic activation."

"Last March, AlphaGo, a program created by Google DeepMind, was able to beat a world-champion human player of Go, but only after it had trained on a database of thirty million moves, running on approximately a million watts. (Its opponent’s brain, by contrast, would have been about fifty thousand times more energy-thrifty, consuming twenty watts.)"

[1] http://www.newyorker.com/tech/elements/a-computer-to-rival-t...
No - not direct compatibility per se, because I don't think it's the responsibility of the argument parsing library to work with the definition. The nodejs runtime[1] uses a lightweight argparse[2] library which is implemented as a plugin. You can then enable additional plugins for argument validation or any other processing you require.

Effectively you end up with two objects, one describing the program and another describing the parsed arguments which should then be passed through a plugin pipeline. The existing runtime plugins[3] illustrate this.

> if there is an automated way to make use of these.

There is using the nodejs runtime, take a look at the source for the mkcli program[4] to get a feel for how it works.

> stepping stone towards a more language agnostic way of defining command-line interfaces

I couldn't agree more, ideally we would implement runtimes in most of the mainstream languages using the pattern described above :)

Hope that helps & thanks for the feedback!

[1]: https://github.com/mkdoc/mkcli-runtime
[2]: https://github.com/cli-kit/cli-argparse
[3]: https://github.com/mkdoc/mkcli-runtime/tree/master/plugin
[4]: https://github.com/mkdoc/mkdoc/blob/master/cli/cli.js
This comment irritates me.

1) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." Even more so, consider what would happen if Google were to update Chrome to not accept these certs. For internal applications, the IT departments of all these companies—which likely total a few hundreds of thousands of users in total—would simply mandate that Chrome is no longer an acceptable browser. For external applications, companies would have to engage in an enormous PR effort to communicate to customers that their product doesn't work with Chrome. These companies have done nothing wrong, but they're the one being punished, as customers don't know and don't care about cert issues.

2) "Updating" can be an enormous effort. As the blog post states explicitly, there are a lot of use cases where updating a deployed app is very difficult, almost impossible, or cost prohibitive. Again, remember that the person being punished here is not Symantec; you're publishing some poor development company who happened to use Symantec—one of the most popular cert providers on the planet—for an SSL cert. Not good.

I'm not taking sides on the issue, because I honestly don't know that much about it. But comments like the above really trivialize the huge impact that something like this will have.
Tools mankind invented so far have been extremely productive as well as destructive. I think worry should not be on if one day the Superhuman AI will take over the mankind, but if we will be able to stop/limit the destruction of that advanced tool in the wrong hands. Definition of who's right or wrong unfortunately contested. We are a species of justifying our actions.

The leverage and exploitation of advanced AI in the hands of malicious people/corporations/states are in a much closer timeline than the "Superhuman AI" could get.

So Open AI kind of initiatives are very important to balance things out. Somehow I am not optimistic.
> as for invasiveness, you're only stating the obvious that there're more and less complex pieces of code yet both kinds (well, all kinds in the complexity spectrum really) can make it into the kernel. that is, this argument cannot be used against incorporating grsec on its own.

You asked for a definition, not an argument. Definitions are supposed to be obvious. Not every line of a reply has to be a rebuttal, just because one part is. :)

> which means the reverse process would reproduce these 'testable components'

The reverse process of how you built up the system (by committing changes), would break the the patchset down into commits. Commits might be patches, but they're sure not components.

A commit can change a line in the middle of a function in the middle of a random file anywhere in the kernel. A component is its own file/module/function that can be independently tested and verified and, most importantly, judged for how well the design-choices in its implementation solve the user-story they purport to solve, compared to other possible implementations.

A random one-line commit can certainly implement functionality—or can fix a bug—but it can't (usually) introduce a user-visible feature on its own. A series of one-line commits can, together, introduce a user-visible feature; but if they do, they need to be merged together into a single patch so that the design they implement can be seen, in order to be evaluated.

If you have take your codebase and just export all the commits as patches, each one might—as it probably originally did—just add one or two lines to the body of some function. But if all the commits necessary for a given feature end up combining into one big, monolithic blob of a patch—or end up extending several functions in the kernel into being large, monolithic functions—then the design of the feature is probably bad, and the patch will therefore probably be rejected.

What the kernel maintainers expect, in such a case, is for you to take your features and refactor them into independent subfeatures, such that each "patch that implements the feature" is fairly small. They expect you to do the same thing to your patchset that is done in a web-app when it is refactored into microservices: to make each component small enough, and non-interdependent-enough, that an argument over the design of the patch can involve each invested party writing their own version to demonstrate their idea; and where each component can be easily ripped out and replaced with one of the alternate designs, without affecting any of the other components.

For a good case of this already happening, look at OpenVZ. OpenVZ was a big, monolithic patch, that was never going to get upstreamed. It was refactored into the individual components of cgroups, the CPU freezer, memory quotas, and the addition of a number of namespace hierarchies. All of these components "add up to" something roughly equivalent to OpenVZ, but they're not OpenVZ. (In fact, they're effectively Docker; upstreaming them basically killed OpenVZ!)
1. He only invests early, so yes.
2. His fund for those investments went 213x

http://fortune.com/2015/01/08/exclusive-is-this-the-best-per...

Possibly the best VC fund of all time.
Package unsafe is in the spec, but converting unsafe.Pointer to uintptr (which is how I'm supposing you'd do your pointer arithmetic) is implementation-defined.

This means I could create a perfectly legal implementation of Go where such things result in complete nonsense. I don't think package unsafe "counts".
The ideas of relativity predate Einstein - his particular view/model still has serious flaws and in the modern rendering leads to non-reality conclusions. In a very funny way, Einstein's two theories of relativity have become religious dogma. Try to discuss this and the usual conduct of "true-believers" is NOT to show where your thinking is wrong, but to simply call you an idiot.

This approach does nothing to convince anyone who believes differently that they are wrong, all it does do is convince them that the "true-believers" are themselves deluded.

This does nothing to advance the understanding of society of the universe around them.
If I can solve an exponential problem with 5 elements in a reasonable amount of time, a mind 1,000,000 times smarter than I can solve the same problem with how many elements in the same time?
Filed away: Office equipment of the late 19th century
Yes, I would agree that for most companies that are in this position rolling your own could easily end up being more problematic than going with gmail or office365. That doesn't mean it does not happen and when it happens they are usually sitting ducks.

The chances of your average law office having an IT staff with capabilities comparable to Google are nil. At the same time the legacy of Snowden has caused a lot of companies to wonder if they're wise to put anything off-premises. And then there's dropbox, weshare and a million other 'handy' services that could easily hoover up and analyze everything that passes through (or whoever hacked them).
refreshing. i think the cost factor isn't brought up enough. none of this is to say that ai isn't going to change the shit out of everything, it's just that the superhuman, "summoning the demon" rhetoric is imprecise, premature and distracting.
Well... Outlandish is to think that replacing a huge amount of infrastructure of a type to another is as simple as your sentence makes it look like.
> I'm surprised to see this kind of simplistic reductionist thinking on HN.

The thinking is in fact correct. The parent should have used a better, more serious, and guaranteed inevitable scenario: war. Bomb the concentrated infrastructure and take down all of Europe's power supply. It wouldn't take very high precision and it wouldn't take a vast number of hits: it would require a few, clumsy hits, which would be nearly impossible to stop.

The present system, which tends to be far more distributed than not (to take down all the power in Europe today, you need to hit a lot of spread out targets), is vastly superior to extreme concentration.
This is how to do an honest sunset of an app. We tried, we hustled and it sucks but we have to stop work. We'll still do more though, so you can keep your data, but this has been stressful as hell. Thanks for supporting us.

It just feels genuine.
>) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people."

not doing something is allowing the previous lack of security standards to put all of those people in danger. there is a tradeoff with every decision.

the entire PKI ecoysystem relies on self management and I think google is making a tough decision, but one that ultimately has already led to better decisions regarding security.
What made you shift to hugo?
For some reason, technical professionals associated with large organizations seem to actively enjoy pretending that basic upkeep is beyond the means of their organization (or has a poor value proposition). I suspect that it comes from a perverse enjoyment of being "pragmatic" in the face of "idealism" but really they're just saying "My org refuses to pay the costs associated with correctly operating the technologies it uses". If you're going to take that attitude, you need to expect that your bluff is going to be called from time to time and you'll have to do some large, unscheduled projects when it happens... that's what being pragmatic actually means: recognizing the positive and negative effects of your options and owning the whole package.
How many of those will actually bring in meaningful traffic? It would be nice to see a list from people who have successfully launched a product on multiple platforms and have traffic numbers to backup their suggestions.
The author was using "literally" chiefly according to its play-on-words definition of the samples having been drawn from literature.

As for the claim that "literally" ever means "figuratively", I have never encountered that use - including in examples offered by those who claim its existence. Literally is sometimes used in figurative circumstance, but I would argue the use is hyperbolic - in the same way we don't say "'days' sometimes means 'minutes'" because people say "I've been waiting for you for days". I have never seen an example that would not have been understood to be figurative but for the addition of "literally".
It was either a bizarre misunderstanding on what will happen on Symantec's side, or "pinned" was used not in the technical meaning.

I could see someone translating "these devices use Symantec's server certs and serve web traffic" to "these devices are pinned to certs issued by Symantec". But if that's the case, they should pay more attention in announcements like this one...
Net Neutrality Role Back proposed by FCC in USA
Part of the premise of Google's plan is that Symantec's customers will experience disruption. If you poll Symantec's customers, the overwhelming majority of them will day "no, don't punish our CA". We didn't need Symantec to tell us that.

On the other hand, Symantec's CA was caught mis-issuing certificates. That affects everyone, not just Symantec's own customers.
If you're going to object to their science, let's hear the actual objections and not just handwavey notions that somehow the science is bad because you don't favor the conclusions.
For those that don't know, Archive Team and Internet Archive are two different groups (though with an overlapping membership).

Internet Archive are a non-profit org that are legally held to high standards, as they should be. They're a very stable place to have data archived. That comes with a few limitations, like not making information available if there's any (even accidental) indication that the upstream site want it kept private - see the comments about robots.txt in tfa.

Archive Team, on the other hand, are a fairly fun and radical group that are far more loosely organised, who will archive what they can when it's needed, and horde it. Fuck your robots.txt![1]

If you can get involved in either organisation, it's highly recommended. They both have interesting challenges and solve them with neat tools.

[1] http://www.archiveteam.org/index.php?title=Robots.txt
Leonard Reiffel, Who Studied Potential of a Lunar Nuclear Bomb, Dies at 89
Uber and Facebook have large apps. Uber is 500,000 lines of Swift. This means someone is already working on these problems before you get there. The video had a lot of good advice. Hopefully, they'll contribute back to the Swift compiler too.
Perhaps my self preservation instinct is completely broken, but why are people so afraid of the possibility that the human race could be replaced by hyperintelligent machines? We aren't perfect (quite the opposite), and a brain that works in the way that ours does has severe built-in limitations. Perhaps the greatest achievement the human race could ever obtain is to create something greater than ourselves. Something that can carry on learning and understanding the universe around us in ways that no human mind ever could.
I think the point there is that if Chrome doesn't trust that CA, then the servers will need to be updated to use a different CA, which will break clients that pinned the old CA.
I don't think the connection will ever be direct enough for the masses to care, there will never been an equivalent of dead bodies hanging out of car wreckage at an intersection.

If someones dishwasher is streaming pirated movies would they care? If their children's bedroom were unknowingly being streamed to pedophiles would the care (obviously they wouldn't like it, but caring requires knowing)?

Vigalantes may be the least worst option.
At this point I'm not making anything and I have poking at the idea on the side for 3 years. I'm currently collecting interest by allowing people to register for the beta.
You seem to know what your are talking about. So let me ask you, if it was not Calvin who was the source of this idea, then which religious leader was?
Tech Made Cities Too Expensive. Here’s How to Fix It
I disagree, a bank should especially be knowledgeable of security (and certificate) issues. I've switched banks because of bad security practices before, it's a simple matter of voting with your feet.
Why don't compilers do amalgamation themselves as a pre-compilation step?
Not only that, but there is a study [1] that shows that traffic speeds do not change significantly even if the speed limit dies have a significant change.

[1] http://www.ibiblio.org/rdu/sl-irrel/
Finally, there's some value in, and a reason to, picking a responsible CA instead of the cheapest or most convenient one!
There's more to it than you've seen so far. Think about environments with hosts starting on demand. You need to encrypt data in flight -> how do you automatically assign a new certificate to an instance on startup? You can't do it with an airgapped system.
> The hyperbole just smacks of virtue signaling, which some people enjoy and others don't.

Why is everything that democrats/liberal say deemed "virtue signaling" now? Do liberals have any genuine principles at all? Are some liberals signaling these virtues to other liberals who genuinely have principles, or is "virtue signaling all the way down"?

(BTW, I'm not American and don't identify neither as liberal or conservative)
> These are some of the most important organizations in the world and you'll cause worldwide chaos

Thanks for that -- reading this comment connected a few thoughts I was struggling with.

Their response felt like "if you don't follow through with your plan to punish us we'll do all of these nice things for you." It reminds me of when my kids get caught doing something wrong and I get "but I'll do all of my chores and treat my siblings nice" along with a handful of other promises of future deeds which I know will be partially or completely not-done. How different the result would have been if they came to me with the chores done and some/all of the promises fulfilled already. It would have been much better for Symantec to have responded with these items in the "completed" category with a smaller number of "we will's".

But to the quote I highlighted: the issue at hand is the past failures indicate that "some of the most important organizations in the world" need to not be trusting Symantec in the first place. They've had a big enough history of failures as a CA to get the attention of Google, who I'm sure isn't terribly interested in degrading the browsing experience of their customers. The choice becomes: (1) Banhammer Symantec, take the resulting pain all at once, visibly and obviously, and get the problem fixed painfully (but it's fixed) or (2) Trust that things will be different this time and if they're not, have another security failure of some kind that results in these critically important company's customers' data being exposed, which is a circumstance that will almost certainly go unnoticed for a period of time, will be covered up if the exposure is minimal and covering up the exposure is possible or may not be discovered at all. The CA system is centered around trusting a handful of rather powerful bodies with an enormous responsibility around the overall security of the Internet. It's not a great model to begin with, but it's what we have and I haven't read about any alternatives that are viable. The only way to keep a model like this secure is to ensure that the CAs themselves are actually trustworthy and one of the more likely ways that will happen is to enforce violations of that trust in the manner Google is suggesting.
Not 'indications', insinuations.

> Given the seriousness of the issue

Is exactly why we should not speculate.

> along with Uber's by now well-established track record for malfeasance

aka, prejudice.

> it's certainly worth looking into what the direct causal factors may have been

I don't deny that it "could have been", but it also "could have not been" - you don't know, and have no way to "look into" or otherwise investigate the situation. If the article did have the means, they did not present anything that would indicate fault.

> It's the very nature of...

I disagree - but if you have a psych degree I'll recant. point #2 is pretty much an ad-hom - no one need to "identify" with anyone, I've seen stressful jobs and people fall apart in them entirely separately to the issue of whether the stress was undue or criminal; your statement is circular in that it assumes that this was one of "those situations", when you don't know anything directly about the environment.

This is all a tangent - you are still arguing "it might be this way", when I never argued otherwise. You are attacking a straw man; The point is the article implied one thing, without substance - whether that thing is possible is irrelevant; it is no more likely, given that we've only hear one side of the story from a party wanting to promote that possibility, but with no direct claim of why they believe it it true.

> the statements in the article from the deceased's family members strongly suggest otherwise

FFS! yes, they do imply that, that is what those family members believe and are promoting, but the article gives no credible reason why they believe that - in fact they give good reason why the family might promote that position without any reason to believe it is more likely than not - not only might they gain much-needed money if it is believed, but it is probably easier to believe it psychologically, given they are the family of the man.

The direct evidence/testomony they give, about actual facts are only that Thomas was highly stressed, due to work, and suffering from anxiety - that is not what I take issue with. What I do take issue with, is the conclusion that this must be because the work environment was unduly stressful - they have no reason to believe this.
I understand that in the current state, not much argument can be made, but if qe roll the clock back to September of last year, a scant 8 months ago, the actions of "both" parties was pretty equally toxic. As I know this will draw fire from one side or the other for not being biased in their personal direction, I cannot and will not support either party due to nonpolitical bias. Analysis of a political state cannot be true if viewed over a (horrible) four month period. The current Democrats took to Reagan policy, as a whole, pretty well. It's just a slightly different flavor.
All that having been spewed out of my opinion hole, is Hackernews going to become embroiled in "my team v. your team" political discussions? I gotta find something new to read on the bus, if so (insert pedantic emoji here)
Thanks for explaining the point, and I note that you are not necessarily supporting what you are explaining.

To be honest, I'm unsure about the whole "make it worth more and they'll invest more in it" argument, but I do think that abandoning net neutrality has a chilling effect on small startups. Or small bloggers, or small anyone.
I'm sure people make plenty of money wrapping OpenSSL in ever more elaborate Enterprise schemes.

But if the net effect is that one bug in a frontend can cause the server to tell the cert server to tell the secure enclave to tell the wire mesh protected crypto coprocessor to sign a bogus certificate then what are we really doing here.
To play devil's advocate, the S&P 500 is also up by over 14% for the past year with likely less risk and drawdown due to diversification.
Firebase is probably an interesting option as it would likely fit in the free tier, and JavaScript friendly, so easy on-page integration.

And you get Google, Twitter, GitHub, etc sign on for free.
Is it that simple? Having veto over certain decisions might solve some vectors, but security isn't an item to check off before you release a product, it's an ongoing maintenance concern because it's living in an ever evolving ecosystem.

Being able to put your foot down doesn't allocate resources for security updates.