241–250 of 311 posts
Earlier quoted context omitted.
Also, the start-up time for the JVM made running applets very sluggish. Java quickly became a synonym for "slow".
You can’t just compare across decades of software and hardware development. Even downloading native binaries would have been sluggish, as the download would have been slow with those download speeds.
Earlier quoted context omitted.
Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded fr…
> WASM proved to be secure and JVM did not. This is an oversimplification — there's nothing about the JVM bytecode architecture making it insecure. In fact, it is quite simpler as an architecture than WASM. Applets were just too early (you have to remember what the state of tech looked like back then), and the implementation was of poor quality to boot (owing in part to some technical limitations — but not only). But…
Your timeline is off by about five years. Java support shipped with Netscape Navigator 2 in 1995, and 95/96/97 is when Java hype and applet experimentation peaked.
Netscape dominated this era. IE6 wouldn’t come out until 2001 and IE share generally wouldn’t cross 50% until 2000 https://en.m.wikipedia.org/wiki/File:Internet-explorer-usage...
By the time Mozilla spun up with open sourced Netscape code, Java in the browser was very much dead.
You nailed the other stuff though.
(Kind of an academic point but I’m curious if Java browser/page integration was much worse than JavaScript in those days. Back then JS wasn’t very capable itself and Netscape was clearly willing to work to promote Java, to the point of mutilating and renaming the language that became JavaScript. I’m not sure back then there was even the term or concept of DOM, and certainly no AJAX. It may be a case of JavaScript just evolving a lot more because applets were so jank as to be DOA)
Earlier quoted context omitted.
Both chrome and firefox lock down the javascript that site is running into their own box. By using a standalone process and whatever mechanism system provided. A pwned site alone isn't enough to cause damage. You also need to overcome other layer of defenses (unlike something like flash that can be owned from it's script engine alone) It usually require multi 0 day to overcome all those defense and do anything useful…
Flash/applets could have been isolated in a process too, right?
> Amazon started the serverless age of compute with Lambda Google App Engine (2008) predates Lambda (2014) by 6 years!
Yeah also heroku and the whole generation of “PaaS” I was never quite sure why we got the name “serverless”, or where it came from, since there were many such products a few years before, and they already had a name App engine had both batch workers and web workers too, and Heroku did too They were both pre-docker, and maybe that makes people think they were different? But I think lambda didn’t launch with docker eit…
App Engine is PaaS: You provide your app to the service in a runnable form (maybe a container image, maybe not) and they spin up a dedicated server (or slice of a server) to run it continuously.
Lambda is Serverless: You provide them a bit of code and a condition under which that code should run. They charge you only when that thing happens and the code runs. How they make that happen (deploy it to a bajillion servers? Only deploy it when it’s called?) are implementation details that are abstracted from the user/developer as long as Lambda makes sure that the code runs whenever the condition happens.
So with PaaS you have to pay even if you have 0 users, and when you scale up you have to do so by spinning up more “servers” (which may result in servers not being fully utilized). With Serverless you pay for the exact amount of compute you need, and 0 if your app is idle.
Earlier quoted context omitted.
Yeah also heroku and the whole generation of “PaaS” I was never quite sure why we got the name “serverless”, or where it came from, since there were many such products a few years before, and they already had a name App engine had both batch workers and web workers too, and Heroku did too They were both pre-docker, and maybe that makes people think they were different? But I think lambda didn’t launch with docker eit…
PaaS, Containerization and Serverless are different concepts. App Engine is PaaS: You provide your app to the service in a runnable form (maybe a container image, maybe not) and they spin up a dedicated server (or slice of a server) to run it continuously. Lambda is Serverless: You provide them a bit of code and a condition under which that code should run. They charge you only when that thing happens and the code ru…
That's how App Engine worked in 2008, and it looks like it still works that way:
https://cloud.google.com/appengine/pricing
Apps running in the flexible environment are deployed to virtual machine types that you specify. These virtual machine resources are billed on a per-second basis with a 1 minute minimum usage cost.
This applied to both the web workers and the batch workers
It was "serverless" in 2008!
> spin up a dedicated server (or slice of a server) to run it continuously.
Absolutely NOT true of App Engine in 2008, and I'm pretty sure Heroku in 2008 too!
Earlier quoted context omitted.
Wasm has a great benefits over those technologies: - Wasm has verification specification that wasm bytecode must comply to. This verified subset makes security exploits seen in those older technologies outright impossible. Attacks based around misbehaving hardware like heartbleed or rowhammer might still be possible, but you, eg, can't reference memory outside of your wasm's memory by tricking the VM to interpret a n…
Btw, is WASM really more secure? JVM and .NET basically have capability-based security thanks to their OOP design together with bytecode verification: if you can't take a reference to an object (say, there's a factory method with a check), you can't access that object in any way (a reference is like an access token). As far as I understand, in WASM memory is a linear blob, so if I compile C++ to WASM, isn't it possib…
WASM, in broswers, runs entirely inside a secure environment with no access to the system.
js->browser->os
|
+--Flash/java-->os
wasm->browser->os
flash/java tho, ran all user code in the same process with full access to the os
Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they don’t really sound much different to me. Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. In all of these cases it’s pitched as improving the customer experience but also conveniently push…
Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded fr…
I'm sure there's a big long list of WebKit exploits somewhere that will contradict that sentence...
Earlier quoted context omitted.
Yeah also heroku and the whole generation of “PaaS” I was never quite sure why we got the name “serverless”, or where it came from, since there were many such products a few years before, and they already had a name App engine had both batch workers and web workers too, and Heroku did too They were both pre-docker, and maybe that makes people think they were different? But I think lambda didn’t launch with docker eit…
PaaS, Containerization and Serverless are different concepts. App Engine is PaaS: You provide your app to the service in a runnable form (maybe a container image, maybe not) and they spin up a dedicated server (or slice of a server) to run it continuously. Lambda is Serverless: You provide them a bit of code and a condition under which that code should run. They charge you only when that thing happens and the code ru…
The fact that lambda would automatically scale to meet whatever QPS you got sounds terrifying.
> Amazon started the serverless age of compute with Lambda Google App Engine (2008) predates Lambda (2014) by 6 years!
Yeah also heroku and the whole generation of “PaaS” I was never quite sure why we got the name “serverless”, or where it came from, since there were many such products a few years before, and they already had a name App engine had both batch workers and web workers too, and Heroku did too They were both pre-docker, and maybe that makes people think they were different? But I think lambda didn’t launch with docker eit…
Serverless refers to the software not being a server (usually implied to be a HTTP server), as was the common way to expose a network application throughout the 2010s, instead using some other process-based means to see the application interface with an outside server implementation. Hence server-less.
It's not a new idea, of course. Good old CGI is serverless, but CGI defines a specific protocol whereas serverless refers to a broad category of various implementations.
Earlier quoted context omitted.
I feel there’s a bit of a disconnect here between Google’s Ads division who are looking to basically do the bare minimum to avoid getting repeatedly spanked primarily by the EU but also now with talk of a breakup in the US and most other parts of Google who I say this entirely unironically are by far the best of all major options with regards to security in both the browser and their public cloud offerings. I’d even…
It is not my intention to be contrarian, but honestly this might be the most incorrect comment I've ever read on hacker news, in several different ways. Sure, some of these might be subjective, but for example chromeOS is Linux with a shiny coat in top, how could it be any better than, well, Linux, let alone miles ahead?
A ChromeOS user isn't apt-get installing binaries or copy/pasting bash one liners from Github. If you enable the Linux dev environment, that also runs in an isolated VM with a much more limited attack surface vs say an out of the box Ubuntu install. Both the Android VM and Linux VM can and routinely are blocked by MDM in school or work contexts.
You could lock down a Linux install with SELinux policies and various other restrictions but on ChromeOS it's the default mode that 99% of users are protected by (or limited by depending on your perspective).