Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ChakraCore GitHub repository is now open

blogs.windows.com

Post reply on HN
Print view View original

221–230 of 324 posts

Re: ChakraCore GitHub repository is now open

#221

Post by hirsin »

nly wrote: post #48
nailer wrote: post #34

Earlier quoted context omitted.

Chakra does better than most of its competition on ES6 support: http://kangax.github.io/compat-table/es6/ (I use v8 and javascriptcore all day but I still appreciate it)

Temporarily perhaps. Most of the gains look to have happened within the long IE11 to Edge 12 release cycle. Firefox 45 looks like it'll leap ahead again, and they're on a 6 week release cycle... I'm not disputing MS have made impressive efforts. I've just yet to see anything from them that would make me put long-term stock in their open source commitments.

Chakra has been well ahead of the other browsers for >1 year now. That lead has been declining (as there's only so much of 100% you can implement), but kangax has always shown it to be ahead.

Re: ChakraCore GitHub repository is now open

#222

Post by carussell »

magicalist wrote: post #210
carussell wrote: post #145

Earlier quoted context omitted.

Neither of those are CLAs. Please correct your comment. I'm particularly perplexed why you linked to that Mozilla document, for two reasons: 1. It says what it is, and as I said above, it's not a CLA. I've signed that document. It's required by everyone to get commit access to the Mozilla repositories. Here's how it works if you want to contribute to Mozilla: you send in a patch, they accept it, and say thank you. No…

> Neither of those are CLAs I see your point now, but the steps are functionally equivalent. The person committing the code has to verify that it's licensable by the contributor under MPL2.0, which means copyright license, patent grant, etc. The specific terms, however are down to the author of CLAs, not inherent to CLAs themselves. The Apache and the Google CLAs are fine, for instance, and look roughly equivalent to…

> I see your point now, but the steps are functionally equivalent.

No, you're equivocating. This part never happens in the CLA-free world: I send a patch in to somebody and they tell me to sign the CLA before accepting it. Or: somebody else sends in to Microsoft some code I've written, and Microsoft tries to get in touch with me to sign the CLA. (This has happened. Not only is it not necessary, but the text of the CLA itself says it's not necessary. The developers of the project don't even understand their own CLA. This is not specific to Microsoft. I wrote about cargo-culted CLAs when Swift was opened up[1].)

> The specific terms, however are down to the author of CLAs, not inherent to CLAs themselves.

This isn't remarkable; I don't know why you chose to make a remark about it. It's fluff. It doesn't legitimize your (still uncorrected) comment, and it doesn't delegitimize mine. Superficially, though, it looks like it does. I don't like this.

> The Apache and the Google CLAs are fine, for instance, and look roughly equivalent to the terms of MPL 2.0.

I'm not going to analyze them here, but let's go with the "equivalence" stance. The argument becomes, "They're equivalent to the terms that are already in the license, so there's no need for them at all." That is, there's no reason not to accept the changes if the contributor never signs the CLA.

Of course, most of the time, the CLA isn't equivalent, which is why you're asked to sign it.

> Can you point out which part you object to specifically? On a quick read I don't see anything in here[1] that's not the equivalent of licensing your code to a project under a major OS license with a patent grant (e.g. Apache 2.0).

To use Apache 2.0 as a specific example, I already wrote a comment about it.[2] The CLA neuters the patent termination clause. This leaves the "beneficiary" of the CLA open to sue anyone over patents with impunity while keeping the hands tied of those on the other end of litigation.

1. https://news.ycombinator.com/item?id=10669891

2. https://news.ycombinator.com/item?id=10896722

Re: ChakraCore GitHub repository is now open

#223

Post by KirinDave »

jrcii wrote: post #31
DoubleMalt wrote: post #14

Even if I'm in danger of stating the obvious, but MS really changed its approach to software. And it is incredibly great having competition in the JS engine market.

> MS really changed its approach to software Their open-source friendliness has unfortunately coincided with a decline of their respect for user privacy and choice (Windows 10). I find the "New Microsoft" bittersweet.

This complaint is so frustrating since odds are many people are reading this from Apple laptops running OSX that does at least as much telemetry. Run Little Snitch and launch apps, type in spotlight, visit a store... hell you'll get regular uptime telemetry dumps even if you don't do anything.

And odds are there is an iPhone or Android phone in your pocket, its software metaphorically top heavy with instrumentation to track your ever engagement pattern with laser-like precision.

But Microsoft takes the brunt of this complaint because they're open, honest, and give you a scale of opt-outs. But mysteriously no one blames Ubuntu for doing the exact same things because... freedom?

Meanwhile, Microsoft has opened their entire core technology stack to outside scrutiny, adopted a radically user-centric approach to OS design, and taken a very risky and user-and-dev-friendly strategy regarding how apps are shipped and created.

I find this ceaseless double standard less than sweet, and indeed very much about bitterness.

Re: ChakraCore GitHub repository is now open

#224

Post by KirinDave »

melted wrote: post #157
magicalist wrote: post #104

Earlier quoted context omitted.

> I find the "New Microsoft" bittersweet. Yes, a much more accurate description than the GP's would be that the "new Microsoft" isn't letting single executive edicts set corporate policy for many things, such as how all teams should interact with the open source communities, instead letting teams themselves make that decision and then supporting them in doing so. The natural result is that many developers within Micr…

I think it's not so much "open source is our future" as it is "if you can't beat them, join them". I'm sure there are plenty of folks at Microsoft who realize that sticking with Windows in Cloud puts them at a competitive disadvantage vs eg Amazon or Google. There are things that _have to_ use Windows (Azure AD, MS SQL, Exchange, Sharepoint), but everything else is only harmed by it. So the litmus test is going to be…

It's sort of comical you say Azures is a competitive disadvantage. Azure and GCE are in almost every way superior to AWS in terms of everything but established marketshare.

If I were going back to step 0 with a startup today, I would not repeat my decisions to stick with AWS. Their stack is slow-moving and frustrating. The VPC rollout has been a slow motion car crash that is only righting itself in the past 3 months. Meanwhile Azure has amazing management tools and GCE has got well-supported containerization as its primary product interface. Both provide competitive rates and subsidies for small tech business, as well.

Re: ChakraCore GitHub repository is now open

#225

Post by ybx »

smacktoward wrote: post #207
ybx wrote: post #194

Earlier quoted context omitted.

But the thing he's saying is that having io.js happen was possible. It's also possible in this scenario too.

Forking is always possible, but it was only practical because the community could plausibly claim to be able to put as much or more effort into building out their fork than Joyent could theirs. Microsoft is a much, much, much bigger company than Joyent. If they decide they want to take things in their own direction, they can throw an awful lot of programmers at making that happen. Which would make standing up a fork…

Forking isn't possible when the code is not there, and when the company that created/copyrighted the code is openly hostile to forks. By them releasing under MIT, this issue is resolved.

As for the manpower behind Microsoft, git has made it very easy to merge code from relatively similar source code - in the cases that they make large important changes, those can always be merged in, and usually without too much work involved.

The only way they could succeed with something like that would be for them to go closed-source again, in which case you're still better off than if they never went open in the first place because you still at least have some code to work from.

Re: ChakraCore GitHub repository is now open

#226

Post by ksp4186 »

morebetterer wrote: post #192
ksp4186 wrote: post #177

Earlier quoted context omitted.

That's correct. V8 license is required in v8-*.h files because they are v8 header files that chakra shim uses. The implementation files has Microsoft license. E.g. All files in https://github.com/Microsoft/node/tree/chnext/deps/chakrashi... Disclaimer: I work for Chakra team (powering node.js)

I see Chakra has caught to up Dec 30, 2015 with the nodejs tree. Which branch are you basing the fork against?

We are basing it off nodejs/master - https://github.com/nodejs/node

Re: ChakraCore GitHub repository is now open

#227

Post by chc »

magicalist wrote: post #196
Someone1234 wrote: post #144

Earlier quoted context omitted.

> Actually it's not clear what else is being collected, because Microsoft won't disclose what's being collected. Is there evidence that only data about usage of Windows store apps is being collected? Microsoft has disclose what is being collected[0]. People just choose to ignore it and making conspiracy theories instead. So where is the evidence that Microsoft is lying? [0] https://technet.microsoft.com/en-us/library…

> Microsoft has disclose what is being collected[0]. let's quote them: > Security. Information that’s required to help keep Windows secure, including info about telemetry client settings, the Malicious Software Removal Tool, and Windows Defender. > Basic device info, including: quality-related info, app compat, and info from the Security level Notably vague, no "conspiracy theories" needed. And you're still missing t…

> It's great they disclose more information than I thought they did, though this list is actually far worse than I had guessed.

If this list is far worse than you'd guessed, why were you worried at all? Nothing on this list looks like personal information. It's basically just a hardware profile and useful but not invasive system information like when your computer crashes. It doesn't appear to record any of my information.

Re: ChakraCore GitHub repository is now open

#228

Post by k__ »

mordocai wrote: post #188
vmorgulis wrote: post #67

> ChakraCore > The MIT License (MIT) > Copyright (c) Microsoft Corporation Incredible! https://github.com/Microsoft/ChakraCore/blob/master/LICENSE....

I'd prefer Apache with its patent clause but what can you do?

Care to elaborate?

Re: ChakraCore GitHub repository is now open

#229

Post by mraleph »

dsp1234 wrote: post #203
mraleph wrote: post #179

Earlier quoted context omitted.

> optimization decisions that the V8 team have made Optimization decisions that V8 team have made are much more universal than it might seem. It is true there are sometimes strange artificial corner cases - but those are often either bugs or temporary solutions that are going to be replaced with something more generic as soon as they start to hurt too much code. > which ends up with having to jump through some hoops…

Optimization decisions that V8 team have made are much more universal than it might seem. That's certainly possible, but maybe a competing VM can do better, but finds that everyone has coded specific V8 optimizations. They may be hesitant to push out their implementation. It may be a better optimization, but it causes existing code to run slower on their VM. Thus back to the original statement that implementation qui…

> The variable has to be in the local scope and can't be in any higher or lower scope, not just a global scope (which your words acknowledge, but your code snippet doesn't)

Sure! I am just trying to say that in my opinion whenever you have a non-local variable used as iteration variable in for-in then you most probably have a bug in your code. I tried to illustrate this with an global variable example because it's a common source of JS bugs - when people leak things into a global namespace by accident.

> Some real world examples[0][1][2]

These links refer to a different bailout reason --- "ForIn is not fast case". The original ForIn support in Crankshaft (written coincidentally by me) only supported this kind of for-in because it was the important case to support and the one where you can get good performance with reasonable investment of time.

Given time and bug reports from people hitting this bailout I would certainly extend ForIn support to cover a more generic case (assuming that supporting more generic case would make some code faster), however just in a couple of months after I landed this initial support I switched to a different project, so I never had chance to revisit this.

This bailout reason is actually not in V8 anymore - as now V8 supports both fast and slow cases in Crankshaft[1]

[1] https://github.com/v8/v8/blob/master/src/crankshaft/hydrogen...

Re: ChakraCore GitHub repository is now open

#230

Post by vetinari »

X-Istence wrote: post #167
rayiner wrote: post #99

Earlier quoted context omitted.

Even if you can easily parse C++,[1] there are a lot of practical impediments to binding to C++ libraries. If an API exposes templates, or relies on constructors/destructors, it's very hard to call that from non-C++ code. For example, SpiderMonkey wraps JS pointers in C++ objects and uses RAII to register roots being held by C++ code with the JS garbage collector. Handy, but more or less impossible to call from non-C…

Clang and LLVM could have been a GCC project instead, but Stallman decided against it. Also, the reason you could only get the AST as a XML dump was because of the same shortsighted mindset.

Stallman also had a reason for that.

If he wouldn't insist on respecting GPL for GCC, there would be no GPL licensed Objective-C compiler, because Jobs would simply never free-source it.

Post reply on HN