It also is found most podcasts; if you hear a recommendation in a podcast, there is a high likelyhood that the recommended company sponsors|ed the podcast -- either through money, access, or 'perks'. Even in cases where sponsorship is disclosed, there is generally no separation between the podcasters and the acquisition of sponsors.
Editorial integrity is long dead on the Internet; its long since time to get used to turning a critical eye to technology-related editorial content.
If you guarantee that your binary has source, it has source. Guaranteed.
If users only want binaries that guarantee they have source, they can insist on only downloading/acquiring binaries from people that guarantee they provide source.
> "Google contributed ports of NaCl for ARM and Amd64."
So, Mono/C# in Chrome? If NaCl/PNaCl becomes available outside the Chrome App Store, that could be pretty exciting -- Mono does an excellent job with AOT performance and mobile-scale memory utilization.
> No, the 'point' you've been trying to push during this entire conversation is that proprietary software gives the end user the 'freedom' to choose not to use it, but somehow you claim that developers don't have that same 'freedom' when it comes to not using GPL licenced code, which of course is a big lie.
No, that's not what I've said at all.
> Stop trying to muddy the water with the meaning of the word 'freedom', we've already established that GPL is about rights, these rights are not provided by permissive licences at all. Again, GPL licenced code assures that the source code will be made available to end users, permissive licences assures nothing of the sort.
The permissive licenses DO provide those rights, if the users choose not to use proprietary software. If they want to use software for which the code isn't provided, they can do that too. Either way, you've given them nothing they didn't already have.
> How can they cause 'significant harm' to our industry? Furthermore how has GPL caused the 'industry immeasurable harm' which you claim it has?
The network effects of GCC/GDB being 1) very expensive to reproduce, and 2) easier to contribute to then replace, and 3) GPL'd, held back the advancement of everything from developer tools (IDEs, static analyzers, debuggers, disassemblers) to JIT implementations for 20+ years.
> Yes the good old communist/religious/political card which always gets thrown by GPL haters when their arguments fall to pieces.
If this essay was any more Marxist, it would be carrying a red flag and speaking Russian.
> And neither of these motivations are in any way inferior to your motivation of wanting to make money.
They're inferior because they're promoted based on intellectual dishonesty and false premises:
- Claiming that you're "granting freedoms", despite the fact that people already have them.
- Employing economic network effects by which the intention -- and end result, should the GPL succeed -- would make it not economically feasible for people to make a choice as to whether they wish to engage in your communal ownership of the means of production.
Fortunately, enough people have seen the logical holes in the GPL's premise that that the attempt to assume control over individuals' use of software, through economic clout of network effects, has not succeeded, despite setbacks such as GCC.
> Your 'logic' is ridicoulus, GPL is no more 'enforcing' sharing than proprietary software is 'enforcing' non-sharing.
You call my logic ridiculous, and then you reiterate my entire point. The GPL is enforcing sharing in the same way proprietary software is enforcing non-sharing.
Whereas the MIT and BSD licenses provide just as many freedoms as the GPL, without enforcing anything. They are, defacto, more free, both for end users and end developers. End users are free to only use open-source products, if they so desire, and developers are free to use liberally licensed open source however they wish to, too.
> Overall your entire line of thought is clearly that developers should not be allowed to share open source unless they allow it to be used in proprietary code, because if they don't they cause 'immeasurable harm' to the software industry.
This is a strawman argument that has no basis in what I actually said.
I think people should be allowed to use the GPL, just like I think people should be allowed to advocate communism. I also think that we should do our best to demonstrate the fallaciousness of their arguments, because they have the capacity to cause significant harm to our industry.
> Whenever I come across someone like you I'm really glad the GPL exists as an alternative.
And whenever I come across someone like you, it is made apparent that the GPL is more of a religion and an a political statement, rather than a reasoned decision made from an understanding of the economic and human realities of industry and our society.
> You dislike GPL because you as a proprietary developer can't use that code, which for some reason you think you have a 'right' to.
You're being obtuse; I've never said what you claim. What I've said, repeatedly, is that the the GPL grants fewer freedoms than liberal licenses such as the MIT license or the BSD license; it doesn't "protect" or "grant" any "freedoms" that the MIT and BSD licenses don't already provide themselves.
What the GPL does do is restrict usage to enforce a quid-pro-quo relationship on its users, with the political goal of leveraging network effects to push a Marxist ideology of dismantling private ownership in favor of shared ownership of the means of production.
If the goal was 'freedom', then it would be enough to provide users with free access to your code; nobody can deny them that free access once it's provided. The goal isn't freedom, however, and painting it as such is both intellectually shallow and dishonest.
> If we speculate wildly, why not an "asm.js restricted operating mode"?
Because we already had Jazelle, and it sucked, and we learned our lesson. A Jazelle that operates on ASCII-encoded bytecode with traps for unsupported JS constructs? No thanks. :)
> Not saying that's a good idea, but I'm not sure why a NaCl one would be either. Both PNaCl and asm.js should reach pretty much native speed anyhow.
Pretty much native and actually native are very different things.
I've had to sit down and hand-optimize critical paths that would not have been viable otherwise, and would have meant discarding a feature, or introducing a significant impact on usability -- and that's on platforms where similar investments in runtime library optimization were already made by the platform vendor, too.
If we're going to throw away performance, it has to be for a good reason. As someone who doesn't spend all day on platform development (as interesting as it might be), my focus is in providing the best possible user experience.
I'd love to do that on the web, but the web needs to punting throwing away solid technology decisions because of the bad technology decisions made in the early 90s when none of us knew what the hell we were doing.
> Btw, the L is not capitalized in NaCl.
Whoops. Thanks. Now I will look less stupid in front of software engineers AND my chemistry buddies. :)
> The point is that NaCl is not portable, just like a native platform such as Windows.
So provide fat binaries. Maximize performance on ARM and i386, with fallback to PNaCL for future platforms that are neither.
> They are even the dominant platforms on mobile.
For a good reason. Adopting their strengths while eschewing their weaknesses (proprietary and single-vendor) would benefit the entire industry greatly.
All you need to do is perform NaCL validation of pages before marking them executable; this is what NaCL already does.
You can either do this through a high-level "JIT API" that generates safe machine code from a validated IR (aka PNaCL), or through a fancier version of mprotect() that validates the actual machine code (aka NaCL).
In a wondrous hypothetical future where processors support a NaCL restricted operating mode, you wouldn't even need to validate; just set the processor state to thumb^Wnacl mode, and define a syscall instruction that switches to direct execution (without actually requiring a context switch to the kernel, just flip an execution flag).
This is why NaCL is so damn interesting, and JS/asm.js is not. NaCL has the possibility of turning our design of restricted execution environments on its head, in a very good (for performance) way.
> And how is the GPL intellectually dishonest? Replacing proprietary software by giving free software developers an advantage is an explicit goal of the GNU project. How is it dishonest?
The usual explanation is "four freedoms" and giving users freedom.
Leveraging network effects to create a communist shared ownership of the means of production is the honest explanation of the GPL, and that has nothing to do with 'freedom', and everything to do with network-enforced Marxist ideals.
> * It's that government-granted monopoly that allows control over other people's means of production. The solution to your problem is simple: fight for its elimination.*
I have no problem with copyright, and I don't want to forcibly eliminate the GPL. I'd be happy for it to die an honest death after careful and rational consideration by the industry.
> ... who are aren't going to make the jump as soon as HTML5 delivers everything they need?
When will that be, exactly? The promise has been a long time coming, and in the meantime, the constitution of the industry is shifting away from a web myopia.
You're asserting that there hasn't been a significant management and hiring shift in engineering departments over the past 5 years, moving away from what became a web monoculture in the post-90s environment, from roughly 2000-2005?
> That doesn't even make sense as proprietary application platforms have always owned the application market.
So you admit the web is ill-suited to serve as an application platform, and is failing to acquire traction in that space despite considerable but ill-focused efforts to the contrary?
Mobile is growing hand-over-fist and web apps developers are still arguing about whether they're fast enough to compete, and whether we could possibly maybe actually move past HTML/CSS/JS sometime in this decade.
It's ridiculous, and you claim it's "reality". Fine, your reality sucks, and there's no inherent reason why it has to win ... and it might not.
No. As someone intimately involved in startup hiring, there's been a massive shift in the make-up of technology organizations.
Mobile has gone from a side-show farmed out to consulting organizations to a mainstream in-house development effort, and the organizations themselves have shifted management and priorities accordingly.
It used to be that almost everyone had a web engineering organization in-house, even non-technology companies. That is changing. Companies like the NYTimes have gone from being grossly unable to manage mobile efforts and farming their work out to subpar contractors, to straight-up building a top-quality team of mobile developers.
Here's the tricky thing about that, too. Those developers, by the nature of where they work in the technology stack, are already quite versatile, and can choose technology solutions outside of the web stack. The problem that most organizations faced originally was that their web departments were a mono-culture and couldn't adapt.
So now you have companies that can and are building technology outside the web, and that means that the network effects that existed before are being torn down. The web tried to leap onto the application bandwagon, and the web failed. Now other technologies are taking over that space.
> I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.).
I included ones you could, such a NaCL. And I should probably have also included the native platforms (Apple, MS, Google), because they're the competition, even if their sandboxing or runtime environment isn't what one might call 'state of the art'.
At the end of the day, it's the two-tier universe that bothers me the most. You're content to foist the JS runtime on everyone but yourselves. Once you implement Firefox entirely as an application running in a JS VM, the argument that JS is good enough might carry some weight.
> There are far far worse systems for evolving widely used platforms.
That's fine, but perhaps it would behoove Mozilla to not participate in dooming the web as a competitive application platform simply due to a misguided belief that the web is defined by HTML/CSS/JS?
Editorial integrity is long dead on the Internet; its long since time to get used to turning a critical eye to technology-related editorial content.