pbsdp

JVM, CLR, Mono AOT complation, NaCL/PNaCL.

A future in which we wind up with architectural support for NaCL-style sandboxing intrinsics, in the same way we saw them be developed for VT-(x|d).

Sticking us with JS for another decade and expecting us to compete against better application runtimes? No.

The same way you'd do it in any runtime? Adopt an adequate representation model of the machine state, and save that state.

> 2. There are lots of reasons to target C. C can be compiled by many compilers, while LLVM IR can only be compiled by LLVM to things LLVM can compile to. For example, game consoles, various new embedded platforms, etc. - they all have C compilers, but LLVM might not support them (and possibly cannot support them).

Is the point to produce something optimal for users, or produce something optimal for developers? Most successful game and application platforms trend towards the former, whereas your work on web technologies trends towards the latter.

> Plus JS has got so fast, it's becoming hard to see the point anyway.

Native is faster. A lot faster. And that's what browser apps are competing against.

It's impossible because Mozilla won't work with Google, not because it's actually impossible.

It's hardly a non-sequitor; the parallels with Marxist thought on common ownership of the means of production are rather undeniable.

Like communism did to economies, the GPL has done our industry immeasurable harm by attempting to enforce sharing, creating closed ecosystems where the cost of market entry was so high that other's had no choice but to participate -- such as was the case with GCC, until the GPLv3 gave Apple sufficient cause to make a massive investment in breaking the GPL's shackles on the compiler/runtime tools software market.

> It could be used as a library as long as the other projects also made their software copyleft.

That never happened. On the other hand, LLVM has lead to a tool renaissance.

> The goal of copyleft is freedom for the users, not "pushing the state of the art forward."

Users already have that freedom. They can simply refuse to use proprietary software. They don't require a paternalistic GPL license to 'enforce' a freedom they already had.

In the relative context of implementing a production runtime, that's "just a bit of register/stack allocation".

If you're hobby-hacking a project, then you may as well just target something that already exists, because micro-inefficiencies that matter on the scale of a deployed production platform probably don't matter for your human-resource-constrained hobby project.

If you're designing the next browser language runtime, or a language meant to be used outside of hobby deployments, there's no point in permanently hamstringing your implementation architecture to save a small amount of implementation time within what is already a large and complex problem space.

Direct: Constraints/requirements directly related to implementing a maximally effecient runtime architecture.

Indirect: Market constraints that drive technical limitations.

When it comes to browsers, Mozilla both creates and exists within market constraints that drive indirect technical reasoning.

Lashing your industry to JS for another 10 years as a bytecode target is clearly not an optimal long-term solution as compared to the current state of the art, but it might make sense as a legacy support mechanism given the indirect technical constraints.

Calling conventions aren't the hard part; it's just a bit of register/stack allocation.

Introducing a browser bytecode and/or sandboxing is not anywhere near the scale of complexity and expense of inventing a new CPU architecture.

It's a policy decision, not a technical decision.

> The GPL protects users, not developers.

The users can already choose to not use proprietary software, so what is it protecting them against? Themselves?

> You seem to think downstream developers have an entitlement to release proprietary software, even if it goes against the wishes of the original authors ...

No, I just believe that the GPL is intellectually dishonest. It's about controlling other people's means of production, with the end-goal of creating a communist ecosystem in which it's essentially impossible to not participate due to inherent market entry costs.

Not direct technical reasons, no.

The only indirect technical justification is in maintaining compatibility with existing browsers, but that falls over pretty fast when you're a browser maker (Mozilla) and refusing to work with another browser maker (Google) on jumping over that compatibility hurdle.

> The only people who want to "control code" are proprietary companies. Copyleft and the GPL is a rejection of this ...

So copyleft/GPL licensing isn't an attempt to 'control' code? Despite the fact that this is exactly what they do?

> ... the main goal of it is to ensure that all users have equal control over the software.

The users already have the choice to use open-source software vs. proprietary software. If they want to have "equal control" over the software, all they have to do is make the choice to only use open-source software.

> I don't know know how you draw the conclusion that the GPL only benefits the author, as the author loses most if not all of the (unjust) powers granted by copyright by publishing under the GPL.

The author enters into a quid-pro-quo arrangement by which they get access to other people's code under terms equal to their own, and they're free to relicense their own code for whatever commercial use they want. It's an attempt to create a communistic shared ownership of code.

C is a heavyweight intermediary language which brings with it a /lot/ of baggage. There's no valid direct technical reason other than financial resource constraints to justify compiling to C (... or JS, for that matter) instead of a more suitable and expressive IR/bytecode.

It's impossible to implement a variety of useful abstractions in portable C -- for example, function trampolines that do not permute register state and do not appear in the callstack after execution.

I've written ARM assembly for iOS apps to optimize carefully for memory ordering constraints and memory access latency (eg, pipeline stalls), and made use of NEON SIMD for certain critical paths.

This has yielded (ballpark) 2x-5x improvements to runtime performance; some operations essentially become 'free' from the application perspective whereas they took a significant hit previously and could cause UI stuttering and/or significant CPU burn (which also directly correlates to battery life consumption).

Assembly is far from dead in desktop/mobile development.

> Users -- those who are actually interacting with a running version of the software -- lose nothing with the GPL. On the contrary, their rights to the code are secured.

They've been denied the 'right' to use proprietary extensions to the software. Those extensions may provide more benefit to the user than the open source software alone: see also, Mac OS X.

That's no less real a 'right' than the 'right' to have access to the source code, which is something they've never lost because open-source always remains open-source, and they remain free to only use open-source software.

> So yes, the GPL does impose restrictions in specific cases to secure rights in the general case.

Those rights are already secured, because nobody forces users to use proprietary software. If they only want to use software where code is available, they have every right to do so.

I'd argue quite the opposite, I think I understand them quite clearly, and I think the facts speak for themselves in terms of how much grief the GPL and GPL incompatibilities have caused our industry.

Sure they do, if they choose to only use binaries provided by those that also provide source code. Which is their choice.

> I can't quite understand people like you.

That's because you've pretty substantially misinterpreted what I said.

I don't think "developers somehow owe you code to use in a proprietary fashion" -- developers are free to place any licensing restrictions they want on their work.

What I do think is that the GPL is paternalistic, communistic, and intellectually dishonest.

Here's why:

- Once open sourced, your code stays open sourced forever. There's no way to "un-opensource" code, and users can make use of it, forever.

- If users want the source code to the tools they use, they are absolutely free to only use binaries from people that provide the source code. If they don't want the code, they don't have to.

Ergo, users already have the "rights" and/or "freedoms" you're pretending to gift to them. QED.

What the GPL actually does is create a quid-pro-quo communist common ownership of the means of production (code) between developers. This has nothing to do with "rights" of end-users, and everything to do with restricting the rights of developers should they choose to participate in the GPL ecosystem.

There's nothing wrong with that system (other than it being unworkable and viral and restrictive, but there's no law against being obtuse), but it is intellectually dishonest to claim some sort of moral or ethical high ground.

The GPL is a simple mechanism to restrict what other people do with the code they write in exchange for using your code, not about "four freedoms" or "user rights". The parallel's to Marxist Philosophy ought to be pretty obvious in the aptly titled "Why Software Should Not Have Owners" essay from RMS: http://www.gnu.org/philosophy/why-free.html

Users can also CHOOSE not to use proprietary software. You're taking away their right to choose to use your software in a proprietary context.

Why would it be better if LLVM and clang were copyleft? Then it couldn't be used in other products as a library, and the entire industry would be set back to where we were with GCC in the first place -- unable to fully leverage our tools to push the state of the art forward.

Apple implemented a full AOT/JIT/Disassembler (LLVM), debugger (lldb), static code analyzer (clang), C and C compiler (clang), and c++11 stdlib, all under a free MIT-like OSS license.

There all built as libraries, can be linked against to build IDEs, JITs, etc etc etc.

So how is it that they don't get along, exactly?

Everyone else gets along; GPL is the outlier.

I don't think anyone in the industry isn't aware of RMS' paternalistic and communistic motivations.

The BSD advertising clause has been dead for years, and it was primarily incompatible with ... the GPL.

The GPL is incompatible with licenses that impose more restrictions than it does, even if those restrictions are fairly limited, like the advertising clause.

I can't say I've ever heard of license incompatibility stupidity outside of the GPL. Lots of GPL problems, though: OpenSSL, dtrace, ZFS. Apple actually dropped GCC and invested in producing the liberally licensed clang BECAUSE of the GPLv3.

Your entire argument depends on the fiction that users can't make their own choices, or that somehow your code can be made non-OSS once released.

Neither is true, and this hokey 'user rights' notion is just a thinly veiled justification for a paternalistic communist view of open source collaboration, in which you want to control not only your own code, but the code that other people write, too.

It wouldn't be so insidious if it was presented honestly, as a set of limitations on freedom for your own benefit as the author of the GPL software, rather than in terms of the moral high ground of granting freedoms.

> In both these cases the 'end user' can choose not to use what is offered.

Exactly -- so what's the point of offering a 'right' the user already has, if it means taking away rights from developers?

Users can already choose to not use proprietary software, they don't need the GPL to enforce availability of the open aource software they use.

Why shouldn't I blame the GPL? If they'd used a liberal OSS license, the code would be open source, unencumbered, and this problem wouldn't exist.

The GPL introduces license incompatibilities; no GPL, no problem.

Do you not see how ridiculous you sound? Working around licensing by building a hackisb fork-based plugin system?

We're in this business to write software for people to actually use.