> A nice-looking bytecode doesn't seem worth the loss of backwards compatibility. The encoding is ugly, but compatibility with existing browsers seems like such a huge win for something that really just amounts to a different encoding.
Laziness. It, like all other non-public services, should be hidden behind a VPN that reduces the attack surface to the absolute minimum.
Ideally you should use something like OpenVPN's PSK HMAC support, which reduces the total code surface visible to external attackers to only the HMAC validation code paths. If the HMAC does not validate, OpenVPN doesn't even try to interpret the contents of the packet (including authentication/authorization).
Couple that with setuid+chroot of the OpenVPN server, and you've further reduced your attack surface.
If you're actually serious about running a larger secure infrastructure, you also shouldn't be using passwords at all. Your servers shouldn't support them, and password authentication should be disabled in the SSHd configuration. You should use SSH keys.
You also shouldn't be sending plaintext passwords to random servers, and you should prefer alternatives such as x509 auth to the VPN, coupled with SSH key auth (or kerberos) to the actual servers.
If you can't use x509/pke/kerberos for VPN/server authentication, then you should restrict the surface of the machines that handle plaintext passwords to just the VPN and web SSO hosts, rather than exposing user passwords to every single server in your deployment.
The goal is to compartmentalize access to sensitive data, such that you 1) reduce the overall attack surface (including by reducing the visibility of centralized hosts managing sensitive data) and 2) reduce the damage that can be done by compromising a hosts, especially hosts that are visible via the internet (and similarly in a large enterprise, visible company-wide).
I'd say Firefox is a pretty good example of how open-source can counter the issue of monoculture by providing the industry a viable platform from which they can challenge the incumbent browser.
When I started, there was no web. The historical context is quite a bit broader, and it helps to understand what the state of the technology was.
When the browser war was fought (and won):
- Netscape Navigator was actually a pretty terrible piece of software. I dare say they deserved to lose. Towards the end, most Mac users were running IE5 -- it was a better browser (http://en.wikipedia.org/wiki/Internet_Explorer_for_Mac).
- There was diminishing market interest in supporting alternatives to Windows because non-windows marketshare (Mac OS X, UNIX workstations) was plummeting. This allowed Microsoft embrace-and-extend to succeed.
- The web development field was nascent at best. Similar to how many web developers are moving into the mobile space today (and bringing their ideas of how to write apps with them), you had Windows-centric enterprises migrating towards writing web sites (not apps!) and bringing their ideas of how to do so with them.
I very much doubt that the web browser war would happen again in quite the same way. Between the availability of open-source browser stacks, the genuine viability of multiple platforms and vendors (iOS, Android, Mac OS X, Windows, and even Linux), and the established web development community (which would have to be co-opted), I don't think it would be quite so easy for someone like Google to 'win' a browser war and then stagnate indefinitely.
No, I'm saying that open-source solves most of the issues with a monoculture, while also being more effecient than vendor standardization when it comes to pushing forward innovation.
The approaches used to run JavaScript at reasonable speed are the same approaches that one uses to implement a "VM", because they are VMs. An AST converted for fast interpretation winds up looking like a bytecode, because it is a bytecode.
If you dug into Mozilla's SpiderMonkey, you'd find this bytecode:
Now, you don't have to compile to an explicit bytecode. V8 and Nitro use an internal in-memory temporary interpretation of the AST, but compile it straight to machine code, and do not have a bytecode interpreter.
There are advantages to this when all the world is sending around JS source code. There are disadvantages to sending around JS source code, which also happens to be why things like source minimizers exist.
Open-source counters most of the issues around monoculture. Remeber that the first browser wars occurred between two closed source products.
In fact, I think that a single OSS project is far more effecient than attempts at standardization across competing products when it comes to user-beneficial innovation.
Look at the open-source UNIXes. Nearly all the value-add has come from cross-pollination of "proprietary" and not-yet-standardized enhancements, which are consumed by users and application vendors targeting those platforms.
> Do we need all the power a PC provides natively to make great games?
I think the market has declared this to be a definitive "yes". Users don't want to waste their hardware dollars so that you can spend them on inefficient solutions.
When your competition takes advantage of the hardware, and you don't, then your application (or game) falls behind in the marketplace.
There's the argument that users are willing to have lesser performance ... for lesser cost. This is true, but quite different from your code performing more poorly than your competition's on the same hardware.
As a hiring manager for over a decade, I can't recall the last time I received a resume from a qualified female applicant for a full-time software position.
Internships tend to be a bit less one-sided, but the skew is still quite high.
This sucks. I want to receive those resumes, for what I hope are obvious reasons, but I don't ever receive them.
Given that, I can't help but wonder whether:
1) You have a completely different applicant pool
or
2) You somehow changed your application process in a way that resulted in a 2:1 female:male ratio.
I don't think those are terrible questions to have. The answers could be enlightening.
> It is not a VM that accepts binary bytecode as input, which is what the person I am replying to wanted. Context matters. And you could have read that yourself.-
Er, so?
> One could argue quite successfully that one of the chief reasons Java (applets) in a browser is a bad design is because of its "standardised" bytecode format, which is what everyone in this discussion thread is screaming for.
Then please, reasonably argue it. I don't understand how the argument applies.
Java applets perform poorly in the browser for a number of reasons, none of which have anything to do with bytecode:
- Java's generational GC is designed around reserving a very large chunk of RAM, and performs poorly if insufficient RAM is reserved. This is a terrible idea for desktop software.
- Java's sandboxing model is broken and insecure, as it exposes an enormous amount of code as an attack surface. A bug in just about any piece of code in the trusted base libraries can result in a total sandbox compromise.
- Java is slow to start and slow to warm up, and applets more so. It historically ran single-threaded in the browser and blocked execution as it did start up.
- Swing does look native, and doesn't look like the web page, either. Applets can't actually interface with the remainder of the DOM in any integrated fashion (eg, you can't have a Java applet provide a DOM element or directly interface with JS/DOM except through bridging), so applets are odd-men-out for both the platform, and the website they're on.
> Flash was able to get by better by virtue of having a monopoly instead of a standard, and thus, has the freedom to change its swf format and bytecode format.
That doesn't even make sense. Flash was better because it didn't lock up your browser when an applet started, and didn't consume huge amounts of RAM due to a GC architecture that was poorly suited to running on user desktops.
Flash sucked because of its extremely poor implementation and runtime library design.
I believe the ideal (for users) would be to target NaCL natively, with a fallback to server-side PNaCL compilation, and an absolute fallback to PNaCL compilation/execution.
I'm not sure what you're trying to prove; javascript runtimes are VMs too.
Java was designed poorly, and it performed poorly. It just so happens that its design was well-suited to long-running servers, however, so that's where it's used.
I'm not a fan of a future in which the only people that can do interesting things (including the use of SIMD intrinsics) are the platform vendors (eg, Mozilla), while the rest of us live in a JavaScript sandbox.
Maybe Mozilla should try writing their entire browser (VM included) in JavaScript/asm.js and let us know how that goes.
- The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety.
- Performance.
- Common widget toolkits providing a common user-experience across applications, from which users can learn platform conventions and be immediately comfortable and familiar with an application. These toolkits allow us to reinventing the wheel every single time. No, bubblegum and spit collections of JavaScript and CSS are not the same thing.
- Standard library which provides the functionality necessary to conform with platform exceptions and integrate with the platform.
- Tools. Debuggers, compilers, and most especially, profilers and deep instrumentation.
- Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't.
- Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult.
I could probably go on all day. I WANT a non-proprietary, open, standardized application platform, but I need a platform that lets me provide the best available experience to end-users, and the web isn't it. I'm writing my software for my customers, and choosing technology over user-experience doesn't do my customers any favors.
10x slowdown doesn't seem worth keeping backwards compatibility. Why even bother?
2x in the best case is more reasonable, but wouldn't a 1x best case (NaCL) be even better, if you're willing to actually drop backwards compatibility?