Woo, and now a company can't have its own internal CA deployed automatically. And how would software with their own certificate store (ie: Firefox doesn't use the system store) be able to harden itself so much? Its just a piece of software like any other.

And its probably not a "globally wildcarded certificate" that's deployed to the browser, its just a CA. And if a CA is trusted, it can sign arbitrary certificates. You want to be able to do this automatically at least in corporate environment, and manually for development tools.

Because somehow Apple doesn't get hit with anti-trust suits over it because anyone with the power to hit them is using an iphone and wouldn't want their convenience to take a hit.

The rest of the world however, has to at least give the law some lip service.

Kittens are much cuter than human babies ever will be.

As someone in a relationship of 11 years and going (about half of that married) with someone I met online... The thing with starting with someone you know meet face to face, is that the first criterias that got you together is physical location and possibly physical appearance. The former is definitely convenient, the later is necessary to most people, but neither are usually the first thing of importance for a potential long running relationship.

If the first thing that gets you with someone is some kind of mutual interest (in my case, it was videogames and computer science interests), you start from there, there happens to be physical appeal too, and then you fix the location, things are much more likely to work out.

You can do that in person to with specialty interest groups (ie: I could have met someone at PAX or something...), and things can go wrong if you do it wrong (pick someone by their picture on match.com), but generally, it seems to be by far the easiest way to go, meet online by interest.

If I put up a torrent of your favorite game, but I hacked up the internals so its different in a way that you can't tell them apart to screw you over for my own benefit...it would be pretty bad.

In the same way, if when you come to buy my copy of some miniature, and you can't tell them apart, but an expert can look at it and notice I made it out shittier material or I wasn't quite faithful to the original.... someone would be pissed.

My point wasn't about devices/patents, but pieces of art/copyrights (ie: miniatures). Its pretty damn easy to copy it after the artist did the original design/color/etc and someone made the matching 3d model.

At this point Uber is known mainly for UberX, but that's not their only product, and its not even how they started either.

I started using Uber for Uber Black, which was (and still kind of is) a mid range/upscale product, depending on how you look at it. Its not the product that gives them their crazy valuation, but there's still more to Uber than walmart-model taxi.

I'm more worried about collectibles. Its niche, but a niche a lot of people on this board probably feel for. Its bad enough with figures and stuff, trying not to get ripped off at conventions or online... Soon it will be rampant.

That said, the vast majority of use will probably be for commodities anyway... Whoops, all my forks are in the dishwasher, time to 3d print one (when the printers get fast enough to make stuff in a pinch)

For software, generally speaking the copy is exactly the same as the original. No one collects software (only their medium), and its unlimited.

Even with 3d printers, objects are limited (you can't copy them indefinitely, you'll run out of material), and right now at least, until star trek replicators happen, they're not the same as the original (unless the original was 3d printed too i guess). There can be difference in qualities, and the originals may be collectibles... just like a painting can be replicated, but its the original that's worth something.

So being able to tell the originals from the copies apart kind of matters this time around.

Monoprice hdmi cables are also gold plated and are 3-5 bucks on a normal day anyway.

There's a 4th reason that gets tossed around that I've never seen actually validated with the idea of "reusing code on the backend and the front-end" but I've never seen a case where that was actually a good idea since it involves exposing so much logic.

In a lot of fields you basically don't have a choice but to render stuff on the server side, for SEO, initial performance, etc. Depends on the field, but in giant e-commerce and whatsnot, you don't really get to choose here. So thats a given. Thus, if you want to be able to use javascript based UI...you either duplicate code, or you go isomorphic.

With stuff like React or Meteor, isomorphic isn't that hard. So its becoming semi-common, when it makes sense.

Node processes its own logic in 1 thread, but it still has multi-process support. So you can use clusters to have multiple instances running at once, or go old school with spawn/fork. It does confirm what you said: it is an old technology as far as multi-core goes, and you're not going to be writing a ray tracer this way.

For I/O intensive load though, just use clustering to have 1 instance per logical core and you're golden.

Node's claim to fame is really just its async-first I/O design. Some other environments are bringing that in now, along with a strong threading model (ie: .NET, between almost everything new being async by default, and the async/await coroutine syntax), but the culture/ecosystem around it aren't following. Also, if your only easily parallel tasks are I/O bound, you're not getting much more out of it than you would in node.js.

Node however, is NOT simple, it just looks simple. Its absurd stream design and error handling alone means that on any reasonably complex application, you need to be one hell of a debugging guru to figure out whats wrong. A junior dev will run home crying, while the same things in most other languages are pretty trivial.

If you're not building a scripting tool (ie: a css compiler or something), don't need javascript on your server for isomorphic apps and you don't benefit from the threading and I/O model in your workflow (ie: your app is CPU bound), stay far, far away.

Now that pre-compilation is pretty much pervasive in any advanced browser development, you DO have "real alternatives" to ES5 (probably what you're referring to if you're mentioning being stuck with it).

CoffeeScript, TypeScript, ES6, Clojure, hell, Scala is available, and you can use Java with stuff like GWT (imo sucks, but Amazon thought it was great for a while).

People keep going back to JavaScript because, aside for a couple of stupid things (a lot of which are fixed with strict mode and ES6 constructs), its actually pretty damn good, and some things that used to be considered hacks or half baked, like prototypical inheritance, are starting to be viewed as superior to the alternative, with good reasons.

But even without that, the reason people will use node on the server, when its not for isomorphic app (which btw, is a REALLY good way to build your app, if you can afford the development overhead and care about your customers), is because the threading model of Node/V8 has very interesting performance and scaling characteristics for I/O heavy applications. It can scale like fucking crazy. http://blog.caustik.com/2012/04/10/node-js-w250k-concurrent-connections

Dependency management on the JVM and the CLR is hard, so Maven is "a lot more than a build tool". In many other environments, dependency management is "comoditized". No one gives a fuck about the build tool being able to handle dependencies in Ruby-land or Node-world. Gem and Npm are good enough. Not perfect, but good enough.

So then you're left with only the actual build tool, and Maven/Ant/whatever are pretty bad at it. Sufficient, but still bad.

Totally agree. Thats why I don't have a license and I just use the subway (even though I'm in my thirties).

I space out way too much and then to ram in the wall when walking out to work. I just prefer to let someone else do the driving =P