yid

> you'll still possibly reap massive perf gains over Hadoop in certain contexts.

Certainly, and unfortunately, the exact point at which Hadoop becomes the better option over big iron is generally an ongoing debate and shifting target. But there's no doubt that such a point actually exists.

> If it's "machines" plural, than you can do replication between the two.

This is the start of a scaling path that winds down Distributed Systems Avenue, and eventually leads to a place called Hadoop.

(Replication and consensus are remarkably difficult problems that Hadoop solves).

Not to be too pedantic, but most of those things have nothing to do with JS.

> figuring out which events are listening to a given DOM element at any given time

This is part of the DOM Specification, not JS. You may be using JS to manipulate and listen to the DOM, but the reason that browsers don't support doing thing X natively is because the DOM Specification does not specify it.

> * sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company

Again, this is about a Facebook client library, not Javascript.

> * no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}")

If you mean the use of eval to change the runtime environment, pretty much every dynamic language supports some form of eval. It would also be impossible to write certain types of code without eval.

> * keeping CSS out of JS, and JS out of HTML

Not sure how this is a criticism of JS.

> * dealing with features tightly coupled to an ancient jQuery plug-in

Again, this is a common software engineering problem, and has nothing to do with Javascript.

I think you've illustrated some of the reasons that Javascript is so apparently unpopular -- often (but not always) people reference some aspect of the DOM, or jQuery, or whatever vendor-hacked snippets from the late 90s that they remember, without considering that the "bad" parts of the language are by now well known, and there exist extremely efficient and standards-compliant, double-JIT'ed runtimes for JS.

> Tracking down things in JS is a timesuck of epic proportions.

I think you mean your codebase rather than JS. There are plenty of industrial JS codebases where this is not a problem.

> and taking a few seconds to comment that this is a low hanging fruit if i need it has helped future-me at least once.

The problem with "fruit" like this is that it depends heavily on the exact version of the JS runtime being used. If the next iteration of V8 introduces an automatic optimization or (worse) de-optimization for your low-hanging fruit, you're left with sometimes odd-looking code for a behavior that no longer exists.

As we've learned from the history of C++, if you depend on undefined/undocumented behavior quirks of a compiler or runtime, you're going to have a bad time. It's better to bump micro-optimizations like this down to a lower-level language. At best, you're buying a constant factor in whatever scaling curve you're trying to beat.

How is it a huge load on the system given that node can lazy load modules? Do you mean disk space?

> So, you are saying the "talent shortage" is a load of bullshit?

You can have a lot of something and still have a shortage.

Yes, it's called "OPT", but is only for students on f-1 visas to get practical training in their areas of study. While it is temporary work authorization, it is not a work visa. There's a pretty huge difference in that h1bs offer a path to naturalization, whereas f-1 opt does not.

This is absolutely incorrect. There are no temporary work visas for people with "pending h1-b applications".

You guys are doing a great job! Some security-related sandboxing options to docker run that people may not be aware of, which are hard to assemble individually from Linux pieces:

  * --read-only
  * --security-opt="no-new-privileges"
  * --cap-drop=ALL
  * --net="none"
  * --cpu-period=
  * --cpu-quota=

> As I see it, npm appears to be acting like there are a lot of unsolved problems in this realm, and in doing so are endangering a developer community that is absolutely full of amateurs. > The problem with npm is that the cost of entry of your "cool stuff" into the hands of a thousand trusting others is too low; there is no delineation between what is authoritative and what isn't.

I agree that npm has been a bit slow with a bunch of important features like package signing, sandboxing post-install scripts, etc. but as a counterpoint to the authoritativeness issue, I would argue that vetting and defining "authoritative" packages is a difficult problem. I'm not aware of any open/semi-open package ecosystem that has solved this problem (please do correct me if I'm wrong).

As an example in the JS world, which of lodash/ramda/underscore/functionaljs should be the/an authoritative javascript FP library? Should they all be marked authoritative? If so, what is the criteria for a new library to also be authoritative? What happens when a library is abandoned? How do you even define abandoned in an open ecosystem?

These are solvable problems, but not easy ones to reach consensus on.

The Redhat-like alternative is to have a central entity employ/pay contributors to audit and maintain libraries, but it's debatable whether npm would have grown to its current size with that model.

> It's not usually core, it's all the plugins by authors of unknown provenance and skill.

This is otherwise known as an active developer community and is a good thing. In any open library ecosystem, it's ultimately up to the developer to carefully choose and vet third-party modules. There isn't any substitute for that.

The alternative is a tightly controlled standard library, but that isn't npm's stated goal. Such a controlled, curated, audited standard library is, however, something that could be built on top of npm, but obviously not vice versa.

So npm being a circus is, in the grander scheme of things, a good thing. Novice programmers will necessarily produce novice code.

edit: if it wasn't clear, I completely agree about the security risks of this project.

> In the ad, SoFi vows to propel its members to “greatness,” but says not everyone fits the bill. “Find out if you’re great at SoFi.com,” the voiceover reads. “You’re probably not.”

If there's one thing the majority of people watching the superbowl love, it's condescension from a corporation.

> Is something like HHVM considered a tech breakthrough?

A largely backwards source-compatible, JIT'ed interpreter for one of the world's shittiest designed but most widely deployed languages? That runs the frontend fleet for the #2 site on the Web? While supporting new core language features and extensions? Yes, I would say that's a breakthrough in interpreter implementation, and thus tech.

The presence of both "so obvious as not to require stating" and "Not saying the blockchain argument win out" suggests that it's probably not as obvious as it seems. :)

Yes, but I'd ideally go to a licensed, brick-and-mortar store for the reputation and reliability over either eBay or Craigslist, if it weren't for the prices and availability of items. My point is that the benefits of centralized, non-blockchain solutions can outweigh what you lose when you go decentralized, and that's something that should be questioned of every new blockchain application.

What about transaction latency, driver/passenger reputations and ratings, local legal compliance, payment for auxiliary services like maps and point-to-point navigation? All those things sound like they'd be worse off.

The end benefit to the consumer being monopoly prevention isn't likely to outweigh the service guarantees of a centralized service.

> There is no reason a blockchain based app couldn't be implemented.

I don't think anyone is doubting this bit. It's the overwhelming current trend of forcing everything onto the blockchain, whether it improves the application or not. The interesting questions (frequently not answered) revolve around why one should do this.

This is so absurdly simple and yet devastating. Reading some of the comments on the Github issue you posted, this stood out (I don't know anything about lucky7coin):

> So disappointing such code was not reviewed by Vern and team before running it on the server where damage could result.

So this code was actually put into production somewhere at some point -- wow. And cursory code review and compiling from source will do absolutely nothing here.

The same-origin policy is not an optional choice that can be "violated".

> For stream processing engines, configuration will be code. Unfortunate, but unavoidable.

How so?

Kafka is a stream processing engine that uses plain old Zookeeper data structures for config.

Edit: Kafka also seems to have the missing features you mentioned if Riemann should be taken seriously as a general-purpose stream processing engine.

...until you realize that you've broken every single NDA you signed, and your (already-tiny-sized) startup finds out who you are, and you're out of a job.

Might be a case of MySQL natively supporting multi-master replication, whereas with Postgres you have to use a third-party/commercial solution.

Especially if you're not using any particularly advanced Postgres features, the operational simplicity of having built-in multimaster replication might outweigh any PG benefits.

The interesting thing here is that you can set the iframe size to a regular desktop-like size, and then use CSS3 transforms to scale the rendered page down to thumbnail size.

If the entire DO netblock is in the proxy block list, then your headers aren't going to do much.

Maxmind offers Proxy Detection based on IPs; presumably they have the entire AWS/Google/Azure netblocks listed in there.

https://www.maxmind.com/en/proxy-detection-service

Still not impossible, just a bit harder when that $5 DO droplet is no longer good enough to proxy Netflix through.

Sounds like top-notch facilities. They'd still be finite though, so how would you decide who gets to use them in order to maximize, say, societal benefit? (Edit: I say top-notch, because you'd presumably simultaneously want universal access and the best talent to work on it?)

Thank you, that makes sense.

> >The NSA reported using 3 hops for data dumps from their bulk surveillance store.

I'm not sure what this means, and you appear to be referencing a comment in this HN thread. I'd imagine that if an entity uses a hardware splitter to intercept all traffic, the number of alleged hops used in a network traversal isn't as important.

An alternate take on this from the title: like any industry, homeland security (for example) is likely to be a tightly knit cluster of people -- you generally network on LinkedIn (and in life) with people in your own industry.

Now at even two degrees away, a single tenuous connection from the author to this cluster would instantly put the bulk of that cluster into the author's "extended network", and lead to the scary visualization shown. This connection could literally be a recruiter connecting to two essentially random people. At higher degrees of separation, the probability of finding such a path increases dramatically, to the point of almost certainty.

In other words, don't use these so-called "extended networks" for any serious analysis, and don't always trust tree visualizations of social networks.