Show HN: Virtual Machines in the Browser - <AUTHOR> http://blog.grunseid.com/2013/arc.html

<comment><USER4> I was hoping it was a finished version of [http://bellard.org/jslinux/](http://bellard.org/jslinux/)

<comment><USER5> Unbelievable. I tried, echo, ls, find, grep, top, ping, whoami, ps, wget, vi, emacs. Everything is there. All in my browser in Javascript? This is fucking cool. I would love a complete vim in javascript that I can use to replace textareas. This would make it possible to simply use _the_ vim.

<comment><USER6> [http://codemirror.net/](http://codemirror.net/)

I am not a vim user, but I guess this gets close:

[http://codemirror.net/demo/vim.html](http://codemirror.net/demo/vim.html)

<comment><USER7> It's the best attempt I've seen so far, but still it's very close from _the real Vim_.

See this: [http://haldean.org/docstore/?vim- problems](http://haldean.org/docstore/?vim-problems) .

</comment></comment></comment></comment><comment><USER8> Reading the comments here... wow, HN must be a depressing place for people who create things. I feel sorry for the author.

<comment><USER9> As someone who gave depressing feedback, I'd like to defend my actions:

I've learned that attention is more important than appreciation. When you introduce a project, it's better to get people thinking about it, nitpicking and even questioning the point of your project, than to get a few replies of "Nice!" and be ignored in the long term.

I've noticed another thing: most things of which I'm initially slightly dismissive fail to reach any success, but the things I'm very dismissive succeed. I've seen products get very harsh feedback and, a few months later, the products were successful, had better user experiences, and their users loved them.

But the visceral reaction to his project may have to do with the kind of expectations we have from web use vs. installed software.

I know some people install anything they happen by, and will try all one-line command line installs and random .pkgs they find, but most people who care about security are wary of installing closed source software from a not-very- known third party, or run arbitrary code in a virtual machine.

When you browse the web, there's an expectation of not worrying about security and malicious code execution. Javascript blurs that line, but it's mostly kept away from the innards of the host. Installed software is more intimate; in some ways, it's like letting a stranger into your kitchen, but not into into your bedroom. Of course, they can do harm in the kitchen too, but the bedroom has implications that go beyond physical access.

HN can be very negative sometimes, and seeing angry or snide comments makes me sad too. You can give concrete, actionable advice and feedback without being an asshole, and no, that's not pretending to be nice, it's simply not going out of your way to be rude. But if you take everything into account, it's better to get discouraging comments from HN and filter them for real information than to be ignored.

<comment><USER8> I think you may be right with the idea that lot's of negative feedback may be good in a way, interesting observation.

I think one of the main reasons why projects like Arc or NaCl started is that the web is that the web is not a very good platform. It was created as a platform for documents, not for apps. I wish there was a platform having advantages of both web and native platforms (Windows, Linux, Android, etc.).

</comment></comment></comment><comment><USER10> (P)NaCl already solves this problem, without such hacks as transparently spinning up a virtual machine.

I don't trust Virtualbox to be especially resilient to attacks from malicious VMs. Chrome's sandbox is well-audited and (overall) is sound. A virtual machine host has a much larger attack surface, and generally doesn't assume malicious guests.

<comment><AUTHOR> Native Client

      1) Is Chrome only.
      2) Can't spawn processes or subprocesses.
      3) Can't open raw UDP or TCP sockets.
      4) Requires apps be ported.

<comment><USER11> While I like the idea of running a VM in a browser (not sure if I'm convinced it makes sense, I still like the idea):

Argument #1 only makes sense if you support a lot of platforms. Right now you only support Mac OS X (according to another comment).

The number of people who use Chrome globally is larger than the number of people who use Mac OS X. Ergo, if you used Native Client and chrome, you'd be more ubiquitous.

Regarding sockets: chrome supports UDP and TCP: [http://developer.chrome.com/apps/socket.html](http://developer.chrome.com/apps/socket.html)

If there's one platform to build on that is going to cover a large number of people and give close to native performance, it's Chrome+PNaCl. I wouldn't tell everybody to drop what they're doing and adopt that target (it's not ready yet). VMs in the browser are pretty nascent, too.

</comment></comment></comment><comment><USER12> This is really cool.

It's completely backwards from my personal usage of the Internet; I get away with browsing online using a Penryn-era Pentium, a ARM-based Chromebook, and/or my Galaxy Nexus precisely because the majority of processing costs are offloaded on "traditional" websites rather than on the browser doing the rendering.

But if this means that application developers won't have to recompile every application under the sun (like, say, ffmpeg or Audacity) to run under asm.js or PNaCl, then I think it could mean that we could skip a decade or two of having to reinvent the wheel.

On the other hand, this feels suspiciously reminiscent of ActiveX, so I suspect you're going to have a hard time convincing people to adopt it if the security diehards warn you of running arbitrary code on your machine (even if it _is_ in a sandbox).

<comment><USER13> "the majority of processing costs are offloaded on "traditional" websites rather than on the browser doing the rendering"

I have not found this to be the case. I find that most websites take a LOT of processing power to display - loaded with flash, scripts, video, etc.

A lot of sites are not really guilty as it is the ad network content inline with the site that pulls all of that computing power, but other sites (boingboing, for instance) generate a lot of CPU use just on their own.

And it gets worse all the time. I suspect that whatever gains we make with efficiency of HTML5, etc., will be immediately consumed by things like the OP is building.

I have a 5 year old macbook air that absolutely does not need to be replaced. Except that I can't have more than 10-12 browser windows open before it's pinwheel city...

<comment><USER12> With the devices I've used, I find that flash content loads and runs just fine provided that there's at most one running on each page and it doesn't crash.

Granted, I find myself enabling Adblock by default on most sites because most ads nowadays are annoying Flash pop-overs. Back in the day, the Linux implementation of Flash didn't support making the Flash embed transparent, so I had to go into Firebug/Web Inspector and delete the embed/object tags entirely just to read the page. While I think that particular bug has been fixed, even today, most of the Chrome tab crashes I run into are still caused by Flash crashing.

It really bothers me how much stuff depends on Flash still, whether it's putting something in the clipboard from the browser, or just Google Hangouts or Facebook deciding to play a "ping!" when a notification goes off.

The only thing "HTML5" means to me is that my ARM devices can offload H.264 video decoding to the GPU, rather than trying to run a cross-compiled Sorenson decoder on the (relatively underpowered) CPU. Everything else under the "HTML5" banner seems to be just increasingly complicated browser-specific extensions to JavaScript and/or CSS.

I've also noticed that the Chromebook and Chrome for Android will deallocate tabs that I haven't used recently and reload them when I switch to them, which lets me have dozens of tabs "open" on devices which are otherwise only capable of handling three or four tabs at once. Of course, this is only reasonable because of "high speed internet"; I remember being on dial-up in the late 90s running Internet Explorer 4 and opening ten windows in the background so that the pages would pre-load in the background while I read the current page.

</comment></comment></comment><comment><USER14> Security wise, this seems like an awful idea: Unless the host is firewalled from the guest, if Arc-style VMs become popular, than you'll have malicious websites starting VMs to scan your host network for unpatched vulnerabilities, and abuse them.

I try to keep my network secure, but e.g. Cisco/Linksys E3000 hasn't received a firmware update in a long time, and it has known exploitable bugs - <USER2> now, the fact that it is only accessible from inside the NAT, and that webpages can't do arbitrary accesses is what keeps all those E3000s from being exploited.

(My E3000 has been running dd-wrt, so it's not vulnerable to _those_ problems; but I had to manually upgrade the dropbear ssh because of vulnerabilities - latest official dd-wrt for it is still vulnerable)

<comment><AUTHOR> Arc apps will require explicit permission to communicate with a local network. This can be enforced at the hardware layer by the virtual NIC.

<comment><USER15> Even better would be to require explicit permission to communicate with any site that isn't the app origin.

A VM can be put on its own VLAN with a traffic routed through a secure firewall. I don't think Arc is as doomed to be insecure as many are claiming.

<comment><USER14> VirtualBox, at least the version I run, cannot do that on its own. You would need to set up the firewall rules on the host. Which is, of course, possible - but not in a cross platform way (linux uses netfilter/iptables, bsd uses pf, windows uses ... I'm not sure what these days, but many users have a 3rd party firewall as well)

It isn't doomed to be insecure, but its security, portability and convenience/usability have a nontrivial tradeoff which is ignored by the original description. If it's portable and convenient, it is likely going to be lacking on the security front.

</comment></comment></comment></comment><comment><USER16> Title is wrong. Virtual Machines are not in the browser, they are in your computer bridged to the browser.

</comment><comment><USER17> From an end-user POV, what will using an Arc app entail? Will it be like Flash Player and Java; ie, you download and install Arc once, and then all Arc apps will just work and be super awesome?

I had an idea like this, but instead of a VM, using a client-hosted server. The big concern I couldn't solve was security. If you have, say, Peggo.. What is to prevent other websites from being malicious and connecting to your locally-installed Peggo VM and trashing it or otherwise exploiting it?

<comment><AUTHOR> > From an end-user POV, what will using an Arc app entail?

If Arc is installed, you're good to go. Everything just works. If Arc isn't installed

      1) arc.js transparently falls back to the cloud and runs the Arc app on a
         server. The user doesn't know the difference.

and/or

      2) Upsell the user to install Arc.

I haven't built the transparent cloud fallback yet.

> What is to prevent other websites from being malicious and connecting to > your > locally-installed Peggo VM and trashing it or otherwise exploiting > it?

The web server running in the Arc app can check the Referer header to verify the request came from a permissible domain.

<comment><USER18> Can the Referrer header not be spoofed?

<comment><USER19> Spoofing it in a client's browser is not possible but it's trivial to spoof referrer headers (or anything else) from a stand alone program. Beyond checking for referrer headers the server should give the client a signed token (returned back by the client to the server) to verify the request is valid. Otherwise if the client is arbitrarily sending requests to the server to "install X, run Y, ..." it'd be _very_ easy to hijack the server for other processing.

As usual this goes back to one of the standard rules of server security: _Don 't trust anything that comes from the client._

<comment><USER20> Spoofing with a client is easily done. In Firefox you can use TamperData.

</comment></comment></comment></comment></comment><comment><USER21> You might want to change the name from Arc to something else. Arc is the name of a lisp dialect written by Paul Graham, and is the language Hacker News is written in. [http://en.wikipedia.org/wiki/Arc_%28programming_language%29](http://en.wikipedia.org/wiki/Arc_%28programming_language%29)

<comment><USER22> Arc the language hasn't been officially updated in 4 years. All names have been used at some point - it's not realistic to expect them to be truly unique.

<comment><USER23> But "Arc" as a name is widely known and used, at least among the HN sort of community, and although it's a niche language it's actively used within that niche. I think you're overstating things; the name "Arc" was not ready for garbage collection.

<comment><USER22> Isn't this a problem that the market will correct? If Arc the language has a significant enough following, then "Arc" in common use will refer to the language. I'm not saying people should go around picking names others have used, but it seems a little heavy-handed to assume that because a few thousand people have an attachment to a name it is now off limits for everyone else. Moreover, at what point does it become ok? There's also Ark the YC company: [http://ark.com/](http://ark.com/) is that fine because it uses a k?

Taking a look at it from a different angle, even in the case of the legal framework for names - trademark - having Arc the language and Arc the VM thing would be fine.

The truth is, if you don't want people to collide with your name, picking a 3 letter common word probably isn't the way to do it.

<comment><USER23> It would be lucky for me if you were right, because there's a name I've fallen in love with and want to use for an open-source project that is roughly as semantically distant from an existing project as "Arc the language" is from "Arc the VM thing". But the market isn't the only factor here. There are also cultural norms, which deserve respect because they encode how people ought to treat each other (or in this case, each other's work). So I worry about that.

<comment><USER22> Yeah, gauging your audience is a different aspect of this problem entirely. If Arc's ultimate audience is intended to be HN that's probably not a very good strategy, but if it isn't, then it doesn't really matter. You're always going to piss someone off if you pick something that isn't very obscure (or made up).

Names are hard. :/

<comment><USER24> Plus Arc is just one syllable and sounds good. That makes it really tempting.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Desktop client disk space is large enough to have a VM for many sites. In the future, if it increases enough to have a VM for every web application _and_ work offline you have the selling point that the app can work during infrastructure failures. People will buy that. Sandbox the networking so it only can call your site and you have solved some of the security problems mentioned. Trouble is, large amount $$$ is behind tablets and their ilk. So you have to work on this for another 10 years when desktops come back. That will happen when Moore's law returns into existence. Light-based computing or analog-fusion-digital computing comes on the scene. What you have is a homomorphism to just a desktop application. The browser has grown to be a glorified dumb terminal that can display rich interfaces, and so the lines are blurred enough to confuse anyone trying to handle the client/server distinction. Best bet is to turn it into a platform that enterprises can use to solve their existing problems. Niche play. Great work, BTW.

</comment><comment><USER26> Neat concept, but I don't see a VirtualBox-based implementation ever becoming mainstream... not that it needs to be mainstream to be useful.

It seems like full blown x86 PC hardware emulation is overkill for what you're doing. As others mentioned, NaCL isn't really the right abstraction layer either.

Perhaps a stripped-down version of VirtualBox could be turned into a "standard" browser plug-in and paired with something like Docker, so you're just running a minimal container image.

<comment><USER27> I like the Docker idea, especially if Arc were providing the base linux VM via read-only mount and the website's Arc App was only a difference image on top of that ... nice and small.

</comment></comment><comment><USER28> It's certainly a great project, but i can't help thinking : so now we're not satisfied anymore with running virtual machines to execute some code, we need the whole OS on top, along with the shell, and the preinstalled programs...

That story reminds me of the last time I tried to compile a blackberry app on my mac a few years ago : Java VM running my code within a blackberry simulator running inside of a windows XP VM on top on my mac OS.

Where will it end ?

<comment><USER29> People prefer this incremental series of hacks to the existential despair of being faced with a cohesive system, say a lisp machine. :-)

</comment></comment><comment><USER30> On Chrome platforms, this could make use of Native Client to run the VM directly in the browser, rather than requiring the installation of an un- sandboxed browser plugin.

</comment><comment><USER31> Should have named it red pill. :)

Seriously though, I was more excited when I thought it was about running Linux inside the browser. Personally, I have no interest in installing an extra VM on my system just to make your development easier.

</comment><comment><USER32> And what happens to the VM when the user closes their arc app? It seems like you could build really powerful tools that leverage saving the state of the VM between sessions. Suppose I build an arc text editor/image manipulator, something where my workflow is boot program --> load file X --> edit file X --> save file X. In theory I could save states of the entire app between sessions, so the whole workflow becomes boot arc app --> edit file... And I could do this for any app I build in arc... Am I getting this right? Because that would be absolutely incredible for building session persistence without a home-brew backend.

<comment><USER33> To me, this is the most exciting part. I'm thinking Dropbox for application state.

<comment><USER34> This would be very powerful.

</comment></comment></comment><comment><USER35> Hasn't this already been done with Java applets? Would the difference here be that instead of running Java, you could run almost any language?

<comment><AUTHOR> > Would the difference here be that instead of running Java, you could run > > almost any language?

More than just any language - any Linux software.

<comment><USER35> And what are the dependencies? What is the lifetime of the VM? It says that Arc uses VirtualBox, does that mean I would need a full install of VirtualBox to use this?

<comment> lost-theory Yes, I just tried it. The first screen on the downloaded installer says it will download & install Virtualbox, and run Virtualbox + Arc upon system startup.

<comment><AUTHOR> VirtualBox is included in the Arc installer. It doesn't have to be downloaded or installed separately.

<comment><USER36> Congratulations! This is a great idea. If I needed port a network and/or performance critical Linux app to the web, Arc offers some unique advantages. However there is some serious competition from Java apps, jslinux, Emscripten w/ asm.js, and (P)NaCl.

I don't have a Mac, so I haven't tried out your demo yet, but ideally you should make this work like genymotion, using the existing VirualBox install in headless mode. This would also make a much quicker install option for existing vbox users. Hopefully you can avoid the mistake YouWave made of interfering with an existing vbox installs.

</comment></comment></comment></comment></comment></comment><comment><USER37> A new, better, richer, open-souce Flash or Silverlight? Well, it could have some uses.

But in my opinion the browser will eventually simply become the OS: you will compile everything to Javascript (or at least asm.js) and use all the interesting APIs from there. Sad but very probable.

</comment><comment><USER38> cool, looks like the natural extension of client-side programming. why should we be limited to running things in the browser while our local machines remain underutilized? just spin up a sandboxed VM via Arc - brilliant! and - like so often - a seemingly obvious idea in hindsight...

should also be great for downloading torrents in a sandboxed environment.

</comment><comment><USER39> Interesting, but dependencies are a long-term killer. You should check this project:

      http://bellard.org/jslinux/

It creates a VM in javascript and can boot Linux.

</comment><comment><USER40> How does one try out this beta? Is this going to be open source?

<comment><AUTHOR> > How does one try out this beta?

Documentation for Arc and arc.js will be available shortly.

> Is this going to be open source?

Arc will not be.

Perhaps Peggo once Arc has cooled.

<comment><USER41> >> Is this going to be open source?

> Arc will not be.

Are you using a commercial license for VirtualBox then (and not the default GPL)?

<comment><USER42> This needs to be answered.

</comment></comment></comment></comment><comment><USER43> I might be off base here but because the processing of data happens on client side is it possible that this could be used to increase privacy through zero knowledge apps?

</comment><comment><USER44> If I have a VM in the browser can I run.. vim in the browser? My customized instance and all that? Or maybe this wouldn't be too feasible for io-heavy uses?

<comment><AUTHOR> > If I have a VM in the browser can I run.. vim in the browser? My customized > instance and all that? Or maybe this wouldn't be too feasible for io-heavy > uses?

vim, emacs, anything that runs on Linux.

</comment></comment><comment><USER33> This is pretty cool. It has always seemed sort of silly to me that I have powerful so many powerful computing devices in my life and yet most of the important applications in my life are inherently centralized and running on someone else's servers in a far away location. Obviously the power of a remote datacenter is necessary for many applications, but for others it seems unnecessary or even like a hindrance.

</comment><comment><USER45> This sounds a lot like reinventing the wheel (JVM). JVMs lack the power of a full linux core, but do you really need it? you just wanted hardware access + native threds (JVM has these and more)

Also this sounds good for just 1 App, but what happens when you try to run more VMs than you have physical cores? And/Or memory, this would directly affect the host.

<comment><AUTHOR> > what happens when you try to run more VMs than you have physical cores?

The VMs are just processes of the host OS. They're multiplexed over available cores, same as ordinary processes.

</comment></comment><comment><USER46> browsers are essentially virtual machines themselves, so to be highly redundant (i.e. java already does this), why have VM's in the browser, which is already interpreting code on its own. The next guy is going to come along and make a VM inside of a VM inside of a VM and lets see how slow we can make the browser when its 5 levels deep in abstraction.

<comment><USER47> This is an actual linux virtual machine... Not a language runtime.

It's too bad that "Virtual Machine" means so many things. Maybe someone has more info on this, but I understand that it was Java who first called their language runtime a "Virtual Machine". Partly motivated because they wanted to create an actual physical machine that ran Java (kind of like Lisp machines). Nowadays with type 1, type 2 hypervisors, and jails/containers/zones, and every programming language on the planet calling their runtime a VM, I'm not surprised that people are getting confused.

</comment></comment><comment><USER48> I like the idea here, but really wish you'd rename it to something which didn't collide with pg's Arc (which runs Hacker News).

There is a lot of awesome stuff you can do with "local, short-lived VMs". I've thought about how to do this securely (using hardware) -- an awesome end state would be letting a data owner with local data, and a code author in the cloud, both mutually distrustful, allow data owner's data to be processed by code owner in a safe way mutually agreed by each. You could do this with trustworthy computing, or a dedicated trusted third party environment on the net, or maybe with MPC someday.

Not sure if Linux or x86 vm is the right level of abstraction; maybe the "peggo" level where you have a higher level might be better for users. Maybe even something like Docker (but on the client)?

</comment><comment><USER49> This project is going to die unsuccessful. The sooner you stop working on it, the less you will lose unless you really enjoy building this for no other reason than doing it and having something you can put on your resume.

People who need solutions like peggo needed can use the Java applet a portion of their users already have, or they could use asm.js and convert their binaries into JS that runs in the browser. Months ago, I saw a post here where I ran a Qt desktop GUI in my browser that was nothing but JS.

I don't see any real projects / sites that would use Arc, because it would be a lot of friction / poor UX for their users, and it is simply unnecessary because there are already usable solutions to client-side computing.

</comment><comment><USER50> This is a terrible idea. The author needs to stop what they're doing right now, from a security context this is really quite dangerous.

Arc uses a desktop virtualisation tool to run arbitrary code on your system. The manifest provides a set of packages to download and install and a series of commands to execute inside the downloaded Arc VM image. A malicious server could use this to run an app that attacks your network, the host, acts as a bot, anything.

I'm assuming that in order to run native code like this, there's no sandboxing. I've seen no mention of it. There's a reason you can't run native code in the browser without restrictions, and this bypasses all of that.

<comment><AUTHOR> An attacker would have three primary avenues of attack:

      1) Escape the virtual machine sandbox.
      2) Denial of service of host resources.
      3) Attack network services.

For 1), virtual machines provide strong, hardware supported isolation of the host. They can't access the filesystem, resources, or hardware of the host, only their own.

For 2), virtual machines also provide strong protection from the denial of service of host resources. Virtual machines can be restricted in memory, CPU, and device use while running. This occurs routinely with virtual machines provisioned on servers.

Network services, 3), are the largest attack vector not protected by encapsulation within a virtual machine. One weapon virtual machines do posses, however, is complete control over the virtual NIC. Every packet sent or received can be inspected, modified, or discarded.

Arc's network policy is not carved in stone. There is nothing preventing Arc from adopting a same-origin policy, like browsers. Perhaps it will.

<comment><USER47> Hey, I'm the guy being negative in the other comment. I'm sorry about that. Honest question: Do you really think this could be deployed on a large scale? Without reenacting the security nightmare that is Java Applets? You better be very sure about that...

<comment><USER51> Java applets aren't isolated from the host OS by the hardware. This is.

<comment><USER52> I don't see the fundamental difference: both run on a virtual machine, and in both cases it is likely that the isolation will be broken by exploits. And just because it's hardware doesn't mean it's less likely to contain bugs...

</comment></comment></comment></comment></comment><comment><USER41> > I want to build apps in Python and C and ship them in the browser. I can't.

Did you try the existing solutions for running those languages in the browser? (pyjamas, emscripten, etc.)

Were there specific limitations that prevented you from using them?

<comment><USER53> Yes, I really wonder if emscripten was explored here... I assume he was doing this all on the server-side (since there's a mention of $25k monthly server bills).

From the link:

> This was painful, expensive, and inefficient. Clients are more than capable > of transcoding video; the problem is browsers aren't.

> Browsers can't run Linux software like ffmpeg, can't run Python, can't reach > native performance, and can't make cross-domain requests.

Depending on exactly what ffmpeg is being used for, the legality of distributing codecs is going to be an issue. Virtualbox VM overhead is non- zero compared to "native performance" anyway so I'd like to see numbers on this versus running in a browser. Cross-domain requests can be an issue, but CORS headers can work (unless he does not control the site in question, or they don't want people making these sorts of requests).

From the post it sounds like this was a YouTube scraper, which basically means that there's no way he could legally be distributing ffmpeg + codecs needed in any case, and also this is against YouTube's ToS of course.

<comment><USER41> > Yes, I really wonder if emscripten was explored here... I assume he was > doing this all on the server-side (since there's a mention of $25k monthly > server bills).

It is on the client, I believe. Literally runs VirtualBox on the client side.

> Browsers can't run Linux software like ffmpeg, can't run Python, can't reach > native performance, and can't make cross-domain requests.

ffmpeg definitely can be run in browsers, as can python. How close to native performance needs to be measured in each case, of course. I'm curious if they compared the performance and found it lacking, or just didn't try the browser options at all.

<comment><USER53> > It is on the client, I believe. Literally runs VirtualBox on the client > side.

Right, sorry I meant the situation that Arc was intended to remedy (from the site):

> I want to build apps in Python and C and ship them in the browser. I can't.

> I ran full steam into this problem when I built Dirpy, a web app that > records MP3s from YouTube. I could have built a native app in Python and C, > but to test, distribute, and maintain builds for every OS is a total > nightmare. So I built Dirpy as a web app, did all the work on servers, and > paid $25,000 every month in hosting costs.

>> Browsers can't run Linux software like ffmpeg, can't run Python, can't reach native performance, and can't make cross-domain requests.

>> ffmpeg definitely can be run in browsers, as can python. How close to native performance needs to be measured in each case, of course. I'm curious if they compared the performance and found it lacking, or just didn't try the browser options at all.

Totally agreed (I was quoting the site there, to be clear) - I am a huge fan of emscripten's approach, and I think it would work really well for this use case. VirtualBox is overkill here, and getting people to install something like this is a huge barrier.

However I still think that it would not be legal to distribute the codecs one would need to do this, and it'd also be against YouTube's terms of service.

</comment></comment></comment></comment><comment><USER54> I think this is awesome! I had the thought the other day that perhaps using a VM or the lightweight container technologies (like Jails or Docker) that we should be able to do this. Glad to see someone is already working on it!

</comment><comment><USER55> This is _really_ cool. Thanks for releasing it to the world!

Of course it is as secure as the virtualbox Sanbox is, but some variation of this statement would also be true for Flash, for Java and a host of other technologies that despite whatever flaws they had did allow a lot of interesting things to be built.

I am here musing, trying to come up with something nice I could build once the Linux-packaged version is made available...

</comment><comment><USER56> Very nice! Games such as Runescape were built into the browser stored data on users computers to track botting. So many of the first gold farming companies developed technologies like this to implement into Botting clients (which were very sophisticated web browsers).

There was a very interesting tech scene that many don't know about around MMO cheating, especially Runescape.

</comment><comment><USER57> "$25,000 every month in hosting costs". Wow, is that right?

<comment><USER22> As I recall, Dirpy had hundreds of thousands of users. That's a lot of video transcoding.

<comment><AUTHOR> Dirpy had three million monthly users.

</comment></comment></comment><comment><USER58> This seems to me as a very good chance to work together with the Vagrant team and win. [http://www.vagrantup.com/](http://www.vagrantup.com/)

</comment><comment><USER59> $25,000 a month in hosting costs...on a youtube ripper? :0

<comment><USER22> [https://news.ycombinator.com/item?id=6219771](https://news.ycombinator.com/item?id=6219771)

</comment></comment><comment><USER60> The installation failed.

The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.

10.8.4

<comment><AUTHOR> Please shoot me an email so I can destroy the bug.

</comment></comment><comment><USER61> Aren't browser plugins like Java and Flash bad?

</comment><comment><USER62> So we use ArcVM (aka VBox--controlled by Oracle) instead of JavaVM(also controlled by Oracle)?

Qemu would seem to be the better choice.

<comment><USER63> Virtualbox is open source - <USER3>

[https://www.virtualbox.org/browser/vbox/trunk](https://www.virtualbox.org/browser/vbox/trunk)

<comment><USER64> So is the entire JDK.

</comment></comment></comment><comment><USER65> I think it's a nice idea, but you should consider adding support for other backend providers such as Docker.

</comment><comment><USER66> it's a 171.5MB app to convert youtube videos to mp3s

I didn't click ok

Maybe 40MBs is ok… :D

</comment><comment><USER67> Sort of maybe at an intersection of what the NaCL hopes to achieve? Mini sort- of-virtualization of x86?

</comment><comment><USER68> Awesome. Glad to see that you got it out the door, Arthur!

</comment><comment><USER69> I'd like to see this come to fruition.</comment>


Google AI project writes poetry which could make a Vogon proud - <AUTHOR> https://www.theguardian.com/technology/2016/may/17/googles-ai-write-poetry-stark-dramatic-vogons <comment><USER2> My favorite part of the article is the hitchhikers guide to the galaxy reference.</comment>


GDPR for Everyone Who Hates Reading Law - <AUTHOR> https://medium.facilelogin.com/understanding-gdpr-9201e1356418 <comment><AUTHOR> The EU General Data Protection Regulation (GDPR) is the regulation 2016/679 of the European parliament and of the council, which replaces the Data Protection Directive 95/46/EC and was designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens (and residents) data privacy and to reshape the way organizations across the region approach data privacy. Commonly known as GDPR, was passed as a regulation on 27th April 2016 — and will be effective from 25th May 2018. GDPR became quite prominent due to the heavy penalties introduced by it for violators — which could be as much as 4% of the annual global turnover or €20 Million (whichever is greater)</comment>


Boeing push to make training profitable may have left 737 Max pilots unprepared - <AUTHOR> https://www.bloomberg.com/news/articles/2019-12-20/boeing-s-profit-push-may-have-left-737-max-pilots-unprepared <comment><USER2> I hate the "everything must be a profit center" MBA attitude. Boeing is a profitable company because they make machines that fly people from place to place safely and efficiently. Part of that is having training, support, service, replacement parts, sales, manufacturing, IT, R&D, and all the other things required to make things fly.

It's easy to sit in a conference room and say "gee, IT hasn't made any money, instead they've spent a lot of it! Let's downsize, outsource, and make our own divisions pay for IT, we'll see whether we're successful by measuring the IT department's profit next quarter." Inevitably, that department makes more money under that regime, but the company is worse at flying people from place to place.

If you're a hardware company, the software should be free. The support should be effective. You should be hosting training events at nice facilities with free pizza because people who know how to use your hardware will buy more of it. If I have to pay for your software, I'm going to be pressured to buy the Light version instead of Enterprise, and I'm going to pay for only one training class and not learn about your next iteration, and you will sell less hardware.

<comment><USER3> Using a throwaway account.

A few years ago I did some consulting work for British Airways. It was interesting in that as far as the planes themselves, and the operational risk of the planes was concerned, the company had their shit together. Decisions made from a safety first point of view. Engineers making the calls. Everything else no object.

But ALL the software around the planes, from the ops to ALL of the b2c was outsourced to hell. Cue a few months later their entire datacenter went down for 3 days, then a massive security breach.

Their idea of agile was to release stuff once every 3 months in a 2 week window.

The thing that I found odd was that they didn't really perceive software engineering as engineering. They had time, money and patience on the aero engineering, but software to them was just another cost center.

<comment><USER4> This was my experience as a contractor for the Navy, years ago. We've had radar systems that can detect planes after a reflection on another plane, but the software is dogshit.

Someone once told me, it's because generals and admirals can see hardware, and fell like they got value for their money. Software, not so much.

Perhaps it's something innate in humans. Remember how Beats headphones used to add weights to feel more substantial?

<comment><USER5> > Remember how Beats headphones used to add weights to feel more substantial?

This was not really true, the original tear down that found weights was of a counterfeit pair of Beats headphones.

[https://www.gizmodo.com.au/2015/07/are-beats-headphones- real...](https://www.gizmodo.com.au/2015/07/are-beats-headphones-really- designed-to-trick-you/)

<comment><USER6> "As a few folks have pointed out, the version of the headphones we tore down was likely counterfeit. We have posted an in-depth comparison of these and a pair of authentic Beats headphones here. TL;DR: the authentic pair is nearly identical to the counterfeit one."

[https://medium.com/@BenEinstein/how-it-s-made-series- beats-b...](https://medium.com/@BenEinstein/how-it-s-made-series-beats-by- dre-154aae384b36)?

</comment></comment></comment></comment></comment><comment><USER7> Two things really struck me in this article. The first was the graph of sales over time. The current boom in sales is the biggest and longest - only the boom from 1985 to the mid-90s comes close in duration. All the other booms seem to have ended in a sharp drop in sales.

The second is the continuing trend - in both private industry and government - to atomise organisations by outsourcing important work. The immediate, formal needs of the organisation will be met by the contractual requirements but informal communications and long term development of people and institutional knowledge aren't paid for and won't happen.

<comment><USER8> >> outsourcing important work.

That reflects the management trend of seeing themselves as the customer and not the developer (of the company). What better way to reduce the number of opinions that must be considered than to turn your employees into service providers?

</comment></comment><comment><USER9> I'm sorry, but what does squeezing jobs have to do with:

1\. Drive MCAS with only one AOA sensor.

2\. Don't tell MCAS to look for (or even think about) bad AOA data or AOA disagreements.

3\. Equip airplane with two AOA sensors as usual, but make the AOA disagree warning light a "value added option" that customers have to pay extra for.

4\. Don't actually bother to tell pilots that they don't have AOA disagree warning lights.

5\. Don't bother to tell pilots that MCAS exists at all.

6\. Don't test MCAS subsystem to see what it actually does with bad AOA data.

7\. Give MCAS a ridiculous amount of control authority, operating cumulatively over repeated applications to exceed what the pilot can manually override.

8\. Change how the trib stab switch has been wired since 1966 and not tell pilots.

How any engineering team let this through is unfathomable. Don't blame the MBAs or the unions. Didn't these guys get the lecture about the Hyatt?

<comment><USER10> You missed the big one that even made MCAS necessary:

0\. Reposition the engine forward on the wing such that the airframe is inherently unstable and needs software for stabilization.

<comment><USER11> The airframe is not unstable. It exhibits positive longitudinal aerodynamic stability. It's positively but _insufficiently_ stable to meet certification requirements, which is what required them to add MCAS.

MCAS is nowhere near fast enough to compensate if the Max were actually unstable.

<comment><USER10> > _insufficiently stable to meet certification requirements_

Sounds like unstable to me. "I am not fat, I am just insufficiently thin".

<comment><USER12> It's stable. In aerodynamics, stability has a specific meaning and it's possible for two things to be stable, and for one of those things to be less stable than the other.

Picture a pendulum that is hinged on a greased axle vs one that is hinged on a high-friction axle.

Both will reach equilibrium eventually (they're stable) but one will do it faster/with fewer oscillations.

The 737 MAX is longitudinally stable, but it doesn't meet certain nuanced requirements of the Airworthiness regs.

<comment><USER10> There is so much doublespeak here. If it is less stable than required for airworthiness then it is not airworthy. Can we agree on that?

<comment><USER12> Sure, but that doesn't mean it's unstable.

<comment><USER10> If it is not stable enough then it is unstable. Where do you draw the bar on stability, if not airworthiness?

<comment><USER12> >If it is not stable enough then it is unstable.

Nope, sorry, that's not what stability and instability mean.

Stability means it will return to equilibrium if disturbed, but the issue with the MAX is that it requires a positive force gradient per the Part 25 Airworthiness Regulations, which the MAX does not exhibit in a specific part of the envelope.

Stability is not a binary condition. The MAX is longitudinally stable in every part of the flight envelope.

"Not airworthy" does not equate to "unstable". Those two terms are orthogonal.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I've read a few stories, with different 'takes' on 'what went wrong'

They're all obviously coloured by the sources/reporter as obviously (in this case) if your pilot/simulator was impacted by cost cuts, then you're going to pin those dead passengers on your pilot/simulator changes. I'm fine with that. I'd do the same myself.

What scares me though, is that even now the story is still a pile of anecdotal tumble-weed.

What do we know? 1) Enough passengers died for the planes to be grounded. 2) These deaths happened due to: 2.1) Larger engines being bolted onto an old airframe 2.2) Plane not being sufficiently updated to compensate 3) FAA being a bit too cozey with Boeing in certification.

"Mistakes were made"

What I'm not hearing is Boeing going through the stages on this.

Where did they make the mistakes? What should they have done? What have they put in place/restored to ensure it never happens again? etc etc

Boeing needs to try to own what it'll take to get their planes flying again. And that requires them to engage with the bazillion people they've pissed off - to defend why this particular cost-cut wasn't why people died.

<comment><USER14> > Boeing needs to try to own what it'll take to get their planes flying again.

I think they will need to meet the EASA at the Canossa Castle so to speak for that plane to fly again. The FAA so completely screwed up the EASA won't trust a word from them for a very, very long while -- not only did they let Boeing effectively certify their own plane but when the fertilizer hit the circular cooling device and the EASA served them a face saving opportunity by not issuing an EU wide grounding order immediately but individual member countries, one by one, banned the plane from their airspace without grounding them. And the FAA didn't budge! Finally the EASA said, fine, the 737 MAX is grounded. And now all the trust and goodwill carefully built between the two authorities is all gone. Getting the MAX flying again in the USA is one thing, getting it through the EASA after this will be an entire different matter...

<comment><USER15> +1 and I wish I could give more for Canossa, that's really what is missing.

From Wikipedia:

"The Road to Canossa...refers to Holy Roman Emperor Henry IV's trek to Canossa Castle, Italy, where Pope Gregory VII was staying as the guest of Margravine Matilda of Tuscany, at the height of the investiture controversy in January 1077 to seek absolution of his excommunication.

According to contemporary sources, he was forced to humiliate himself on his knees waiting for three days and three nights before the entrance gate of the castle, while a blizzard raged. Indeed, the episode has been described as "one of the most dramatic moments of the Middle Age"

[https://en.m.wikipedia.org/wiki/Road_to_Canossa](https://en.m.wikipedia.org/wiki/Road_to_Canossa)

I also really enjoy Norman Cantor's description in "Civilization in the Middle Ages," where he takes a more cynical view of the actions involved.

</comment></comment></comment><comment><USER16> Wasn't the whole point of the 737max to all planes with new engines (which were more efficient but changed significantly the flight characteristics) to be flown by pilots without having to re certify?

As I understand it, airlines or the faa only permit pilots to be licensed for 2 airframes at a time. So a 747 pilot can also fly 737s but not other commercial airliners. That's a problem because if the new boeing isn't a 737, existing pilots can't fly it without giving up one of the other two. Airlines dont want that as it makes introducing the new plane a massive pain in the arse and it means either dumping old planes or running a complex mixed infrastructure.

So Boeing effectively had pilots fly a 737 simulator that would make the actual Max fly when/where/how they wanted.

Except the simulator had a bug where if a single sensor failed it crashed the plane.

So the trigger of the issue is a single point of failure in a sensor but the fundamental causes are needing to not change pilot certification and/or only being allowed 2 certifications at a time.

<comment><USER17> Boeing backed themselves into a corner they weren't going to get out of without major restructuring. The 737 is an old airframe design. They've extended the design for decades with longer cabin and more powerful engines. But underneath it all is the 60s era design considerations.

They needed a new regional airframe design a decade ago. Something to iterate on for the next 50 years. And that could be introduced while the 737 was phased out. A smaller version of the 787 would have a been a good foundation.

<comment><USER16> Broadly I agree, but the corner isn't just boeing: the faa and airlines banned pilots from knowing more than 2 (I think) air frames a while ago. That's anticompetitive and any progress. It's the reason Boeing is still selling 50 year old designs: no one will buy anything newer.

What exactly to do about that, I'm not sure...

<comment><USER18> > the faa and airlines banned pilots from knowing more than 2 (I think) air > frames a while ago.

The FAA does not limit how many type certificates that a pilot has. However, large airlines have policies that likely do limit their pilots to flying two airliner types.

Source: commercially-rated airplane pilot.

</comment></comment></comment></comment><comment><USER19> begin off topic rant:

Dear bloomberg, ny times and other major news outfits.

Please sort out a decent micropayment solution that works on _all_ news sites without hassle.

I'm willing to pay you a couple cents to read articles linked to by HN and other aggregators. However, I will never subscribe because I'm not interested in the other 99% of your content.

end offtopic rant

</comment><comment><USER20> This is business as usual. Nothing will change if executive doesn't get jail time. I'm surprised that Boeing hasn't' been sued yet for the Lion and Ethiopian crash.

</comment><comment><USER21> [http://archive.md/zvv0X](http://archive.md/zvv0X)

</comment><comment><USER8> I initially read this as Boeing push to make _trains_ profitable...

<comment><USER22> Might as well now that they proved their entire culture of design is unsafe, at least train doesn't usually have variable angle of attack.

</comment></comment><comment><USER23> This is what happens when a company becomes too big and entrenched.

</comment><comment><USER24> Initially thought that this said they were trying to make trains profitable.

</comment><comment><USER25> I am totally ready to see the last of the Boeing threads on HN. It's like Groundhog Day.</comment>


The Company Suing Apple Made Batteries for a Crappy Tesla Knockoff - <AUTHOR> http://motherboard.vice.com/read/the-company-suing-apple-made-batteries-for-a-crappy-tesla-knockoff

<comment> o0-0o A123 sounds like a real scam. They took 250 Million of US taxpayer money in the form of a grant, declared bankruptcy, sold their assets to the Chinese, and now are suing Apple. If they were my neighbor and acted like this, I'd consider moving to a better neighborhood.

<comment><AUTHOR> If they were my neighbors, THEY'D move to another neighborhood.</comment></comment>


Static Hosting with Amazon S3 and Cloudfront - By-Jokese https://byjokese.com/blog/Static-Hosting-with-Amazon-S3-and-Cloudfront.html <comment><AUTHOR> I'm using Hugo [0], and this is how I host my site.

I have a small bash script that will generate the static files, push to S3, and issue a CloudFront invalidation.

Also, my bill is ~0.60 USD/month.

[0] [https://gohugo.io](https://gohugo.io)

<comment><USER2> I have done the exact same thing with a Makefile :)

[https://blog.martinlee.org/posts/how-its-made-pt2-or-hugo- in...](https://blog.martinlee.org/posts/how-its-made-pt2-or-hugo-in-s3-and- cloudfront/)

</comment></comment><comment><USER3> Be sure to check out Stout as well, we use it to deploy our static apps and it works and does all the config for you: [http://stout.is](http://stout.is)

</comment><comment><USER4> I also use S3, add also a bucket named www.example.com that redirects to example.com bucket.</comment>


Uber Makes Economists Sad - <AUTHOR> http://www.bloombergview.com/articles/2014-07-09/uber-makes-economists-sad <comment><USER4> It's absolutely no surprise that the majority of people might prefer a particular resource to be allocated by lottery instead of auction, because they can't afford to outbid the wealthy minority for those resources. There is a lot of social conditioning in our society to accept auctioning as normal for resources like land and housing, but for things like taxis or tickets auctioning hasn't been practical to date so the socialization isn't there and this more basic preference, arguably rational for the average person, shows through.

You see similar attitudes in many other areas. E.g. when it comes to spectrum auctions, people complain that the big telecom firms just get even richer by buying up all the spectrum. Well sure, that's what happens in markets. Those with the most money buy all the resources.

<comment><USER5> _It 's absolutely no surprise that the majority of people might prefer a particular resource to be allocated by lottery instead of auction, because they can't afford to outbid the wealthy minority for those resources._

That would be rational if the supply was fixed; but since it isn't (the number of drivers increase with the surge pricing), it's far from clear whether the average person is negatively affected by the temporary price increase (as far as I know, surge prices usually last a very short time).

<comment><USER6>
       (the number of drivers increase with the surge pricing)

I doubt there would be suddenly tens of thousands of additional drivers more after the WC final on Sundary in Germany to drive all the people home from the bars and public viewing locations, when more than 80% of the population is watching the game.

        (as far as I know, surge prices usually last a very short time)

Well, that's already sucks enought, when it's late in the night and you want to get home. Might as well wait until I can get public transport in the morning...

<comment><USER7> Having talked with many Lyft drivers about it, the drivers are definitely aware of what times pay better rates and many of them choose to schedule their workdays around it. I don't know if it works for one off events like the WC but it definitely increases supply during evenings and late nights.

<comment><USER8> Hey guys,

Need a ride? Here's a $25 credit for you to try Lyft - it's like a cab, but costs less. To get the $25, just download the mobile app for iPhone/Android and type in "FREELYFTD" in the payments section of the app. If you're in a pioneer city, you'll get free rides on top of the $25!

To order a ride, tap "Request Lyft" and your driver will pick you up in minutes to get you where you need to go

Feel free to share it with friends & family!

</comment></comment></comment></comment></comment><comment><USER9> I don't have a problem with surge pricing, but what I do have a problem with is when a driver cancels my ride so they can get a higher surge rate. Example, I was in LA trying to go from Downtown to Venice, I got an Uber for 1.75x normal rate. Waited about 10 minutes while watching the driver head in a different direction on the map, and then all of a sudden, they cancel. I go back to reserver another driver, and what do you know, it's now 3.25x rate.

That shouldn't be allowed. You should be locked into the first rate that you request a driver at. If the driver cancels, and the area now has a higher surge rate, Uber should recoup the difference in cost from the drivers next trip because they fucked a customer over.

<comment><USER10> Yeah, that's completely horseshit. At a minimum the rate ought to stay locked in for you by virtue of the agreement to take your fare, and the difference should come from the offending driver's next fare as a disincentive.

<comment><USER11> You always have the option of not choosing Uber.... You can even start a blog and inform others of this practice. Finally, you can complain to everyone you know and encourage people not to use Uber...

Or just ask the government for more legislature I guess...

<comment><USER10> Or, a customer service flaw that disincentives use of Uber's service due to the unreliability of their contractors could be addressed by Uber, as a cost to those unreliable contractors, as I suggested. What part of my post (or any other posts I've made on this topic, for that matter) suggests I feel government legislation would be appropriate here?

EDIT: Furthermore, this is already something Uber does with their star rating system. This would just be a logical extension of that.

</comment></comment></comment></comment><comment><USER12> New York didn't kill surge pricing. They limited how high surge pricing can go during emergencies. A pretty huge difference.

 _Uber will not totally eliminate dynamic pricing during emergencies but will instead cap how high its rates can go based on what it charged consumers over the previous two months._

[http://www.slate.com/blogs/moneybox/2014/07/08/uber_price_go...](http://www.slate.com/blogs/moneybox/2014/07/08/uber_price_gouging_not_during_emergencies_in_new_york.html)

<comment><USER13> What are the minimum requirements for a situation to be considered an emergency?

<comment><USER14> From the AG's announcement (and Uber's announcement promises to abide by this definition):

New York's law against price gouging (General Business Law §396-r), was passed in the winter of 1978-79 in response to escalating heating oil prices. It defines an "abnormal disruption of the market" as "any change in the market, whether actual or imminently threatened, resulting from stress of weather, convulsion of nature, failure or shortage of electric power or other source of energy, strike, civil disorder, war, military action, national or local emergency, or other cause of an abnormal disruption of the market which results in the declaration of a state of emergency by the governor."

<comment><USER15> So now they can't do surge pricing when it rains? The main reason I like Uber in NYC is because it is impossible to get a taxi when it's raining. Seems like this would ruin a big chunk of their value proposition.

<comment><USER16> It doesn't say they can't do surge pricing; they just have a cap on how high it can go during an emergency.

</comment></comment></comment></comment></comment><comment><USER17> >> that price gouging actually makes everyone better off by ensuring greater supply and allocating the supply to (approximately) those with the greatest demand

I think the issue is that it's not those with the "greatest demand" but those with "the greatest demand and can afford higher prices" i.e. the service isn't equally available to people during surge pricing, it skews heavily towards the wealthier, "(approximately)" massively understates the significance of this.

<comment><USER18> The idea is a rich guy can still quickly get to the beautician during a disaster. He's earned this right and is basically just cashing in on years of hard work skimming off the top of workers's 401K trading fees--these workers were forced to select from a few mutual funds chosen based on family ties with the executives, but he worked _damn_ hard to be born to the right board member.

Highest bidder would work great and allow excellent prioritization if everyone had roughly the same means. This is a bit like economist worship of the Coase Theorem--it completely falls apart when you factor in marginal utility of additional dollars to individuals at different levels of wealth.

<comment><USER19> No, that's not the idea. If surge pricing was in effect all the time --- if travel pricing was always an auction and drivers were kept scarce to keep prices up --- then Uber rides would be a service for the rich. But disasters are rare, and the surge multiple is merely the equivalent of several Uber rides instead of one. Meanwhile, the alternative to surge pricing is a high likelihood of not getting a ride at all, because disasters suppress demand. It's hard to see the class-warrior logic in this situation.

( _Later, you edited your comment_ )

It's a caricature to suggest that "Coase" is, to economists, a license to apply the free market to every public policy problem.

Meanwhile: you have to actually make the case that there's a distributional problem with surge pricing for Uber rides. If the alternative is no rides at all, then surge pricing makes some people --- not all of them rich --- better off while making nobody worse off.

<comment><USER20> Yep. Instead of "expensive Uber rides" during a snowstorm, you get "no Uber rides." (A shortage, in other words.)

Thanks, Albany! Well-done.

</comment></comment></comment></comment><comment><USER21> I live in New York and use Uber a lot. Last week during the tropical storm, I opened the app to use it but found the surge pricing to be too rich for my blood. I hopped on the train instead (it was only 2 blocks away anyway).

Surge pricing works! That car I would have used stayed available for someone that needed it a lot more than I did.

<comment><USER22> _That car I would have used stayed available for someone that needed it a lot more than I did._

That car stayed available for someone willing to pay more money. Between two people of roughly equal means, that's a good proxy for "needs it more." Between two people of vastly disparate means it's not.

<comment><USER10> Right, but that's a fundamental feature of capitalism. If equality of access to a non-essential luxury between those of disparate means concerns you, don't worry about the symptom, worry about the underlying system. On the other hand, if unequal access to, say, 5 star hotels in Times Square on New Years Eve doesn't bother you, then neither should surge pricing.

<comment><USER23> I'm not sure taxi service qualifies as a "non-essential luxury"; there are times when it isn't (a rainstorm, for instance) and I think that's why it draws the political interest that it does.

PS I inadvertently downvoted you, unfortunately there doesn't seem to be a way to upvote it back. Sorry...

<comment><USER10> No worries on the inadvertent downvote. I do, however, have to take issue with the characterization of a taxi as an essential. :)

Seriously, though, even in a rainstorm a taxi is a non-essential. It's nice, and I'd certainly prefer one if it's raining, but it isn't essential. There always exist alternate modes of transportation that are going to be less expensive (public transit, Zipcar, your own car, or an umbrella and your own two feet). It's not as though one, bereft of an affordable taxi, can never reach one's destination.

I just don't see how Uber can possibly be construed as an essential, except maybe in _highly_ exceptional circumstances. You're hiring someone to chauffeur you to your destination with an expensive computing device, via a similarly expensive data connection. How is that anything _but_ the definition of a non-essential, luxury good?

<comment><USER23> You're a mother carrying groceries and a kid and you have to walk ten blocks. Is it as essential as medical treatment? No, but it's a substantial degradation of your quality of life if you get priced out of it. I think the political attention on the topic speaks for itself as to how essential the public views it. And we're not just talking about Uber here, we're talking about taxis in general: if Uber drives taxis out of business by undercutting them during ordinary circumstances, there won't be any around to undercut Uber during a surge.

</comment></comment></comment></comment></comment></comment><comment><USER24> The problem with Uber surge pricing is that it's not just the drivers who get paid more; Uber gets paid more too. That doesn't make sense because surge pricing is actually indicative of a failure on Uber's part (they weren't able to recruit enough drivers). From an economics perspective, all of the surge price increase should go to the drivers and Uber should be paid the same or even less. That would also make surge pricing much easier for Uber to defend politically.

<comment><USER25> No, Uber didn't fail anyone. To the extent there's a failure somewhere, it's the monopoly the municipality holds on taxi medallions, which artificially limits supply of taxis overall.

<comment><USER19> Municipalities and states hold "monopolies" on licenses of all sorts; the argument that says medallions are bad public policy because they're monopolistic applies equally to many other forms of licensure, for instance zoning.

<comment><USER25> While this is true, what makes taxi medallions so unique is the price discovery. This is one of those rare things where you can see, quite unambiguously, the direct effect of the monopolistic behavior. Other things like zoning tend to be very complex and ambiguous, but taxi medallions are simple. The effect? NYC taxi medallion prices have grown by 29% annually over 30 years. As someone in the investment world, that might be the single best performing asset class I can think of, all for the privilege of taking someone from point A to point B. I noticed airlines don't need medallions - how has that worked out?

[http://www.theatlantic.com/business/archive/2011/10/the- amaz...](http://www.theatlantic.com/business/archive/2011/10/the- amazing-1-million-nyc-taxi-medallion/247158/)

<comment><USER19> Did you just suggest that it's easier to start a commercial airline than it is to get a taxi medallion? Have you ever paid attention to the drama about who gets what gates at which airports? Or watched local political battles over the addition of new runways at an airport?

<comment><USER25> No. One's supply limited by the government, the other's is not. At the end of the day they both just transport people from point A to point B. Owners of planes have gone bankrupt 1,000 times since 1980, while owners of taxis have the single best returning asset I can think of. Do you really think government meddling (or medallioning, heh heh) hasn't been about 85% responsible for this otherwise incomprehensible result?

<comment><USER19> The supply of available airport gates is absolutely limited by governments.

<comment><USER25> Well this is going nowhere. I don't know why I try sometimes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> This mis-characterizes the Economist's wonder at price mechanisms - as though this one characteristic in a vacuum should be a shining example of the "invisible hand" (subtext mine).

The key market assumption that is missing that would make this a wholly positive pricing activity, is that the marginally increased demand also comes with a marginally increased supply at a marginally higher cost, which it doesn't in these cases. The supply market does not expand in order to cover more customers in most cases, with everyone paying a slight penalty for the transaction/logistical cost, all it does is take a saturated supply market and price out the lower tier.

So if Uber was able to dispatch MORE drivers for a slightly higher cost at surge times (arguably easier with Uber than with traditional taxi companies), that would actually be closer to the Pareto efficiency that economists like. Perhaps I am wrong but it doesn't look like that is what happens in the case of Uber.

<comment><USER5> Why do you think Uber doesn't dispatch more drivers? As far as I know, one of the reasons for the surge pricing is to get more Uber drivers on the street, increasing the supply.

<comment><USER27> One of the stated reasons. We've yet to see any evidence that this effect actually occurs and is significant.

This is the same company that tried to eliminate its competition by ordering cars and canceling them at the last moment. I like their product enough, but their business practice track record suggests that they are not on the up and up.

Particularly in NYC where surge isn't just long events like New Year's - <USER2> kicks in during half hour rainstorms as well. I highly doubt there's any significant supply change in that kind of time frame - in which case Uber is simply price gouging without any of the claimed positive supply effect.

<comment><USER28> > Particularly in NYC where surge isn't just long events like New Year's - > surge kicks in during half hour rainstorms as well.

Surge pricing also encourages uber drivers (who decide their own hours) that are about to end their shift to end a bit later to take advantage of the surge.

<comment><USER27> Sure, all of this is logical and works in a thought-experimenty way. I'd like to see some data that backs this up though.

Market reality and what looks great on paper are often two very separate things - we in startups should know this better than anyone else.

How many extra cars get on the road during these short surge events? Is it worth charging everyone 2X if it brings an extra 1% of supply? 5%?

One thing you get used to after dealing with startups for a while is to listen to what they're _not_ saying as well as what they're saying. Uber, along with all other "sharing economy" startups, like to trumpet their social-good side (see: AirBnb and the "helping poor New Yorkers pay rent" narrative). The fact that they've released nothing even remotely resembling data regarding the supply-boosting effects of surge pricing is suspicious. My suspicion is that the effect is not substantial unless during extended surge events (say, New Year's), certainly not substantial enough to placate people looking at 2X, even 3X fares.

</comment></comment></comment></comment></comment><comment><USER19> If you want to hear two libertarian-leaning econ professors talking about Uber, including some novel arguments against it (they both support Uber, of course, particularly the surge pricing), check out this week's EconTalk:

[http://www.econtalk.org/](http://www.econtalk.org/)

<comment><USER29> Direct link: [http://www.econtalk.org/archives/2014/07/michael_munger.html](http://www.econtalk.org/archives/2014/07/michael_munger.html)

The episode is pretty good. It's fun to listen to economists' perspective on these services after being absorbed in the tech.

<comment><USER19> I liked it fine, but I found the economics to be extremely predictable and the public policy analysis to be very shallow. For instance, Airbnb is to Mike Munger an unalloyed good; I found myself yelling at the car radio "but what about the mob hotels?"

You knew Roberts and Munger were going to like Uber, and, of course, they do.

<comment><USER29> I think that was to be expected, based on the fact that they are both professed libertarians. There are other episodes where the guest doesn't share Roberts' ideologies though.

</comment></comment></comment></comment><comment><USER30> The problem with this is that the people who get the rides in surge pricing are not the ones with the most demand, but those with the most resources. It's an inherently classist system. The surge price, to that rich person coming out of work to catch a cab to that upscale restaurant for dinner is pennies. But the surge price to the single mother who desperately needs the cab to get to school to pick up her kids on time before the school closes and they have to walk home in the rain with out jackets is breaking the bank.

This does not make things "better for everyone" as the article argues. It only ensures that the wealthy always have it good, instead of having to compete for the limited service with everyone else. And it doesn't give the rides to those who truly need them most.

<comment><USER31> So let's do this for housing as well. Let's assign the best houses by lottery for a fixed price so that the poor mother of two has a fair chance, as opposed to a rich person housing their lover on the side.

I think symbolic legislation around feel-good examples like cabs allows society to maintain the fiction that somehow it's not already completely capitalistic. It's like a safety valve.

<comment><USER32> Complaining about pricing of cabs is rich people wanting their bit of capitalism to feel fair to them.

For many people a cab is something you use when all other transport options have failed and you need to get somewhere now even if it means eating just beans on toast for the next week.

<comment><USER33> Yes. I had a friend once who took a cab to work when her bus didn't arrive, even though it meant she would have a net negative income for that day, so she wouldn't lose her job.

</comment></comment></comment></comment><comment><USER34> The author appears to have little or no grasp of human psychology. People object to cash being the only tool utilized to increase supply which is totally reasonable. Why doesn't Uber try =any= other incentives? There's not a huge difference between "no one getting ice" and "a few rich people getting ice". That is what people object to and it has nothing to do with politics.

Also, my read of Uber's agreement was that it would only cap surge pricing during natural disaster-type problems based on some formula for recent surges.

So the economists will only miss studying true price gouging.

<comment><USER35> > There's not a huge difference between "no one getting ice" and "a few rich > people getting ice".

The idea behind demand pricing is that people who need it the most will be the most willing to pay; pricing is the only real general mechanism we have to express need/desire. With Uber, I sometimes take Ubers even though my destination is straight down a bus line (to avoid waiting at the bus stop, if the weather is bad, etc). If the price was high enough, I may decide to just take the bus, which means the Uber is freed up for someone taking a trip that's less amenable to purely taking transit.

You are of course right that this effect is distorted by the fact that the wealthier you are, the less valuable money becomes, so you're willing to pay more for things that are less important. It just seemed like you were being a little reductive and ignoring the actual intent (and partial result) of demand pricing.

<comment><USER23> _...pricing is the only real general mechanism we have to express need /desire._

There is another one, actually. It's called voting. And it's how taxi regulations came about in the first place.

<comment><USER35> Wait, what? How does voting determine who gets a taxi? I'm not sure what jurisdiction you're thinking of, but none of the ones that Uber operates in holds a referendum every time N people are trying to hail M taxis (where N > M).

Of course, voting expresses needs and desires, but that's in an entirely different sense of the word than it's being used in this context. The only way one could mistake the two is if they read my comment COMPLETELY without context: without having read the article, the headline, or any of the HN comments page....unless you're just nitpicking semantics to be contrarian because you have nothing else to contribute, in which case I'm not interested in wasting any more of my time.

<comment><USER23> _Wait, what? How does voting determine who gets a taxi?_

How does it not? Voting represents long term needs and desires, like the desire for an orderly, reliable public transportation system. Voting determines whether there are going to be taxis at all. It's not a matter of semantics. I read the article, the headline, and many of the comments, including yours. And I don't see any 'context' that supports a flat statement that pricing is the _only_ way people express their need for transportation, sorry.

<comment><USER35> As I said in my comment:

"Of course, voting expresses needs and desires, but that's in an entirely different sense of the word than it's being used in this context....The only way one could mistake the two is if they read my comment COMPLETELY without context: without having read the article, the headline, or any of the HN comments page....unless you're just nitpicking semantics to be contrarian because you have nothing else to contribute."

I understand that you're trying to be deliberately obtuse here, but in the small event that you're not, i'll make it blindingly, incredibly, extremely, amazingly obvious that I'm talking about allocating resources at the time of purchase, for each potential purchase. I mean jesus,you claim to have read my comment, and yet you're pretending that I didn't give an explicit example of what I was talking about and you're continuing to talk about something that couldn't be more off-topic. Here is the example again, in case you somehow (???) missed it:

When there is a rainstorm, and there are T taxis, and P people who want a taxi, and T < P, there is no jurisdiction in the world who holds a referendum (or has Congress decide) that taxi 1 is assigned to Bob, taxi 2 to Fred, taxi 3 to Alice, etc. To make this ultra-ultra-ultra-clear, so hopefully even you will understand it, when I said prices are the only mechanism of expressing needs/desires, I was incredibly ridiculously obviously talking about "needs/desires of each person for a given product at a given time", since that is the context of the article, the headline, the HN comments, et al. The fact that you're pretending not to have understood any of the context of this and insist that "voting" is an expression of every individual's demand for a product at every relevant moment in time (which again, is the topic of the conversation here) is either incredibly disingenuous or mind-blowingly stupid. The fact that voting can set the value of T beforehand(in the above example) has NOTHING to do with expressing each individual's need/desire for the taxi product at every relevant moment of time (which, again, is what the conversation about and what you were attempting to rebut when you claimed that voting could take the place of pricing in that regard). I mean really, Jesus Christ

<comment><USER23> I understand what you're saying, and I'm not being deliberately obtuse. The "context of the article, the headline, the HN comments, et al", in case you missed it, is a _policy_ discussion on whether surge pricing should be permitted. You narrowed that context down to the moment of getting a taxi; I deliberately broadened it back out. It was not intended as an insult, only as a reminder. And I never suggested that "voting could take the place of pricing", only that it was another way of expressing need or desire in the long term.

You took for granted that "of course" those people also had the power to express their desire politically, you just didn't think it was relevant for the point you were trying to make. I get that. In these discussions, I see a lot of comments along the lines of "give the consumer choices" and "let the market decide", putting the focus just as you did on the point of transaction. But in a democracy the consumer can also exercise choice by voting to limit the market. I'm making the point that those choices shouldn't be discounted simply because they weren't made at the time the immediate need presented itself.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> >drivers couldn't be lured out of their warm beds on a cold and needy night.

This is not only about warm beds, it's about risk and reward. A snowstorm increases the chances of getting into a car crash by many factors, and if the reward (surge pricing) isn't big enough, drivers won't be willing to risk it.

</comment><comment><USER37> It creates supply! (It doesn't. It stratifies the haves from the have-nots efficiently.)

Ice after a storm? Definitely let market forces dictate who keeps insulin cold and who sips chilly mint julips.

This is the underlying issue with Uber and blind disruption of regulatory frameworks. Regulatory initiatives often get propelled with moral issues. They then get calcified and twisted by economic forces.

Disruption of those economic entrenchments is laudable. Avoiding the acknowledgement of the collateral damage to the moral reasons for existing regulatory systems creates obstacles to acceptance. Fix that last bit and market forces can play freely.

<comment><USER38> > _It creates supply! (It doesn 't. It stratifies the haves from the have-nots > efficiently.)_

Are you disputing that surge pricing increases supply? It should be trivially obvious that it does.

Your "moral" arguments only apply if you treat Uber as the sole provider of transportation. If Uber ever starts actually supplanting cabs, your argument will have some merit, but cab companies have not died off. They have a real competitor now, which I think is a good thing, and in markets like SF where the cab companies woefully underserved the population it's now actually possible to reasonably get a ride. But the cabs still exist, with the same regulations as before.

If Uber disappeared overnight, the supply of cabs would not increase. The supply of overall transportation during a storm certainly would not increase. Given that Uber is an _addition_ to the existing transportation infrastructure, and not a replacement, what exactly is the justification for claiming that Uber needs to abide by the same pricing regulation that regular cab companies obey? There's a good argument for why _safety_ regulations should apply to Uber, but that doesn't apply to things like pricing. Regulation of pricing for cab companies is not a natural consequence of the fact that the cab companies are in the business of transportation; it's a consequence of the fact that cab companies are seen as providing basic public infrastructure. Do you view Uber as basic public infrastructure? I don't, and I don't see how you can make a compelling argument for that position.

</comment></comment><comment><USER39> Part of me things that this could have been avoided with better messaging and product design. Instead of calling it "surge pricing," they should have said, "There are no Ubers available. Your expected wait for an Uber is 110 minutes. Would you like to offer a bonus to your driver?"

Then you could select a bonus, and drivers could choose to pick you up or not pick you up based on whether they thought the bonus was enough.

</comment><comment><USER40> At 8x, I would have considered driving for UberX myself during events (although probably not NYE, just due to drunk driver risk).

<comment><USER34> And that is exactly the point.

</comment></comment><comment><USER41> This article misrepresents the facts, and the headline is false in two different ways. (False claim about surge pricing, unsupported claim about "economists")

The linked Slate article is more accurate.

Mods, please switch the link to point to the more accurate less blogspammy Slate source.

</comment><comment><USER42> Price Gouging and the Poor - <USER3>

[http://bleedingheartlibertarians.com/2013/10/price- gouging-a...](http://bleedingheartlibertarians.com/2013/10/price-gouging-and- the-poor/)

<comment><USER43> The root of the problem is the question of whether social values should have weight in a situation of limited supply, ie. when taken to its extreme: should one person be allowed to fuck up the whole planet because they have more monopoly money, thereby destroying the whole species and all future generations.

Conventional capitalists will say yes without thinking, then spout whatever view-confirming stuff they can find (like this URL). Market-libertarians say a market will evolve to cater for the resource impacted that all people value, though we haven't actually seen that happen yet (observe the failure of the carbon credit scheme). Socialists say yes, we should treat one another with respect because fundamentally we're all in this together.

All views have some credence.

<comment><USER42> No, that is not the root of the problem at all.

The root of the problem is that humans have evolved anti-market biases that served us well when living in tribal communes but which are Pareto inefficient when living in large billion person societies.

<comment><USER43> I'd call that a capitalist view. In all its brevity, it exhibits one of the absolute top fallacies of capitalist thinking when in "have evolved anti- market biases" you allude to markets being some kind of 'natural' state of affairs. This falsity was neatly summed up by George Soros: _Classical economics is based on a false analogy with Newtonian physics_... by which he means, if you listen to or read any of his numerous interviews, that there is no 'equilibrium' and self-regulating nature of the market is fundamentally more a well-spun, oft-repeated tale than a self-evident truth. Further smackdown can be applied through reading _Debt: The First 5000 Years_ (which conventional capitalist economists positively hate).

Leaving that aside, you'll note that I alluded to the ugly truth (the world is inherently limited; ie. there's sure to be critical resource shortages given current trajectories). From my perspective, any so-called _anti-market bias_ will evolve right about the time we see mass starvations due to stupid short- sighted environmental management, potable water shortages, etc. - ie. if you think we've got _anti-market bias_ now ... my wager is that you'll be shocked at how hollow the notion becomes in the relatively near future.

But the view does have some credence, ie. some forms of decision-making don't scale. But the obvious answer to that, far from assuming a self-evident path of decoupling historically present social, environmental, cultural and other local factors from economic decision-making across an inherently globalized god-like market that will deliver us from all ills as you imply (clearly, it won't), is perhaps to evolve newer and more subtle modes of collective decision-making that include market-like consideration of these factors and scale more effectively. That would be more like the market-libertarian view.

</comment></comment></comment></comment><comment><USER44> Price discrimination only matches supply to greatest demand if everyone has the same income. But I then again this is Bloomberg so I'd be shocked if I saw any real economics on their website.

</comment><comment><USER14> Is a (potentially dramatically) smaller set of riders of more evenly distributed financial means strictly better than more riders that skew richer?

Egalitarian distribution is in some ways a social good (it's a good antidote to the hedonic treadmill for just one thing). But at what smaller size does this more equal ridership become strictly worse than a bigger less-equal ridership?

</comment><comment><USER45> Serious question -- there appear to be common two ways of allocating scarce resources in situations like this: either through price, or through semi- random who-gets-through first (see also online ticket sales).

Why do people think the latter is "more fair"? Are there any interesting alternative methods of allocation that are equally lightweight?

<comment><USER20> > there appear to be common two ways of allocating scarce resources in > situations like this: either through price, or...

But the quantity of the resource (Uber drivers) is not fixed. If you allow a higher surge price, you get more drivers.

</comment></comment><comment><USER46> An important yet neglected aspect of surge pricing model is that it fails to correctly account for decrease in demand. As such, one can probably argue that fixed prices capture the real market better in the expectation sense.

</comment><comment><USER47> Perhaps we can get some special surge pricing setup for only the economists.

</comment><comment><USER48> Why are economists who defend surge pricing not pushing for "real" markets where drivers set prices?

</comment><comment><USER49> By the same logic, I'm sure that rent control makes economists sad, too. However, if that didn't exist, NY and SF would just be real estate speculation ghost towns.

<comment><USER19> I think that sentiment is pretty far from uncontroversial amongst economists of all stripes.

Here's a survey paper:

[http://econjwatch.org/articles/rent-control-do-economists- ag...](http://econjwatch.org/articles/rent-control-do-economists-agree)

Here's what Matthew Yglesias --- hardly a standard-bearer for libertarian economics --- has to say about it:

[http://beyondchron.org/matthew-yglesias-is-right-the-rent- is...](http://beyondchron.org/matthew-yglesias-is-right-the-rent-is-too-damn- high/)

(Yglesias is not an economist but is a decent proxy, since this is kind of his "beat").

<comment><USER35> For the life of me, I don't understand why we don't replace rent control with means-tested cash grants if we really care about displacement (and pay for it out of a Land Value Tax, but that can be an orthogonal issue). The way we have it now, we're screwing arbitrary renters (including poor ones) that happen to move between apts more often, to pay arbitrary renters that happen to move less often (including rich ones). I don't understand how anyone could say it's good policy with a straight face.

</comment></comment></comment><comment><USER50> Technical aside: this page took forever to load, after being laid out. Is that due to a WebFont issue? Too much stuff dumped into the onload handler? It's been over 60 seconds of blank, laid out page now and I still can't see the content.

This is pretty much worst case when it comes to web technologies. Show the text first, let the extras come in slowly. Showing everything _except_ the text is pretty horrific.</comment>


NetApp believes ZFS could put them out of business [pdf] - <AUTHOR> http://blogs.sun.com/dillon/resource/HitzDecl.pdf

<comment><USER2> WAFS sounds like it borrows a lot the research done 20 years ago by the Sprite group.

[http://linuxmafia.com/faq/Filesystems/filesystems- metadata.h...](http://linuxmafia.com/faq/Filesystems/filesystems- metadata.html)

[http://www.eecs.berkeley.edu/Research/Projects/CS/sprite/ret...](http://www.eecs.berkeley.edu/Research/Projects/CS/sprite/retrospective.html)

Ousterhout's LFS paper is from 1991 and according to Wikipedia NetApp wasn't founded until 1992.</comment>


Recursive redirects with AWS Lambda - <AUTHOR> http://dangoldin.com/2016/11/13/recursive-redirects-with-aws-lambda/ <comment><USER2> I did exactly this to in order to use cloudfront signed cookies with lambda/apigateway. API gateway only allows you to have one set-cookie header per response, but 3 are required for cloudfront signed cookies. (See thread: [https://forums.aws.amazon.com/thread.jspa?threadID=205782](https://forums.aws.amazon.com/thread.jspa?threadID=205782))

UPDATE: Looks like there is a work-around that uses the fact that the set- cookie header is treated as case-insensitive by the browser but not apigateway. Genius.</comment>


Google's geographer-in-chief - <AUTHOR> http://www.fastcompany.com/3060811/most-creative-people/google-map-quest <comment><USER2> I find it weird that people contribute to Google maps. I use OSM most of the time and contribute whenever I find a path that is missing, but I would never contribute to a closed data silo like Google Maps (at least not without being paid).

The very idea that someone _owns_ mapping data seems weird to me. It's the real world, people can just go and see what's there, how can someone claim to own location info?

<comment><USER3> I contribute to both, and use both.

It's possible to find value from both for different reasons, realise they excel in different ways, and my contributions to each reflect my use of each.

Into Google I add/update business opening hours, locations, photos of the inside of a shop or space, reviews of the produce or service on sale (with more positive reviews than negative). These are the things I find of most value when I travel to another area or country.

Into OSM I add/update paths, geographic features, detail on the ground. Things that aid navigation, location, a more factual rather than subjective view of the world around. These are the things I find most of value when I am travelling or researching history and wanting more factual information at a fine level of detail about a collection of places (an area).

I find no contradiction between contributing and using both, because my reason for using OSM and Google services does not boil down to ownership of data.

That said, there is an area in which I actively promote OSM... cycle navigation.

The Garmin maps are exorbitantly priced and always out of date. I promote (on over 300 cycling forums that I run) the use of Open Cycle Map, the ability to load these for free onto a Garmin, and the quality of them across most of the world.

But then... you didn't mention Garmin ;)

<comment><USER2> I use a Garmin device with OSM maps. I bought it specifically because it can read them. Buying that thing was one of the best investments I made in recent years.</comment></comment></comment>