It's a good name and shouldn't be changed. They're different enough things to be discriminable via context.
Also, there's Automatic Reference Counting and people who don't care about proper casing ("Ios").
Lastly, if the matter gets out of hand, it's regrippable by adding the author's name in front of Arc: Paul's Arc, Grun's Arc, Noah's Arc.
Has anything else significant been written in Arc? @pg talked about the language for a long time before its release, but it seems to have stagnated since then.
I feel like I'm missing something. If users have to download a 140MB, what, browser plugin? Is it a browser plugin? Then how does the "in the browser" argument hold up?
Sure, if this gets popular like Flash once got popular then it might work (and it might be the best thing since sliced bread, really), but as long as it doesn't, how is this different from just packaging ffmpeg into a plugin and having users install that? (to take the "Why" link's example case)
The blog post is a little over a month old. The installer is 60MB now.
Arc is a daemon that runs on your system, like DropBox. Browsers can use arc.js and instruct Arc to run native code in lightweight Linux virtual machines.
Arc is a stronger approach than maintaining browser plugins. Arc apps, like web apps, are up-to-date every time they're opened. They also have full access to their Linux virtual machine and can use Linux programs as-is. Browser plugins can't provide that.
It still sounds like a kind of browser plugin to me, but the "plugging in" is done at the OS level instead of within the browser + the OS (as with, say, Flash having an application component and a browser plugin component).
It really doesn't seem like a bad idea, though, so long as the sandboxing is done safely and securely.
I certainly think this is very neat but the bottom line is that a user would have to be able to install arc the first time they want to use an app built on it. No matter how trivial you make that process it still sits on the other-side of the 'all you need is a browser' argument. For a lot of folk the distinction is not important but for others its quite different. For example I work medical imaging where we deploy in tightly controlled hospital environments where I can guarantee a browser will be installed (increasingly not just IE). Getting anything else widely rolled out is simply beyond our $$ power and thus we wouldn't target a technology like arc (sadly as I can think of a couple of places it would help). It sucks but you really don't want to give potential customers any excuse to not bother trying the product.
Great concept! Would be nice if it's an open standard. Instead of having to download and install your App, people can implement and choose from different implementations. This makes several things possible:
1. Different virtualization/container engine: Different platforms have different good stuff. I would use LXC/docker for Linux since it's super lightweight, and disposable. Even NaCl should be an option.
2. Standardizing would also help defining how resources should be allocated/re-used on local machines.
3. People who make web apps gets to use a single standard instead of tracking different technologies. (Think about Java Applet vs Flash vs Silverlight) Any site should be able to access it through a port on localhost. It's THE port, using THE protocol. And that's it; it should work on all hosts that have the service installed.
4. It brings a chance to have it accepted by major browsers makes as a core service, which makes it easier for wide adoption.
I could've swore I had just seen this the other day. Oh wait I did[1]! And it's still only on Mac OSX and does not appear to have advanced in the past 2 months.
Well, ok, it has advanced some it appears and has significantly more/better documentation than it did.. but I'm still waiting for it to work on my Linux box :(
This is really cool, and I'm disappointed there's so much hate going on in here.
I agree with points that there is a distribution challenge, but I think if Arc can get small enough, it'll be like SilverLight or Flash. This could make a huge difference for in-browser games that don't want to mess with asm.js.
Unfortunately such a plugin as this would be of type NPAPI. Which Google has just announced that they are starting to deprecate and have stopped accepting submissions to the Chrome Web Store for NPAPI plugins.
So there's never going to be support for this to be able to run on a Chromebook.
I see there are some pro's like we have it somehow with Java today. Maybe we can really start an environment which suits for all browsers to run a piece of code in it, which is cross plattform compatible and makes use of all the great possibilities that we have on a linux machine. Great there!
Now the con's:
With great possibilities come great responsibilities. Where do you want to start to avoid having a super-amount of unsecure boxes? Package a ready-to-use program into the box with a "just one click in your browser to start"-button, having users who run code they never look at, from people they never saw (but for some weird reasons trust), in boxes they just one-click-download-and-run? Or did I just got something wrong?
- arc.io with documentation, demos, and examples in Python, C, Ruby, and Node.js.
- Support for other developers to build and ship Arc apps.
- Installer is 60MB, down from 140MB.
- Updated to the latest VirtualBox v4.2.18.
- Bug fixes, security fixes, and performance improvements.
49 days ago Arc was ready for a blog post. Now it's ready for laps
around the track.
I think this is a valid resubmission. Also, he submitted it before and got burnt down. Apparently (if you see the set of comments here right now), people's moods are better today.
For size, Arc's installer will continue to shrink (it's down to 60MB from 140MB). A custom built VirtualBox should be quite small. However, VirtualBox does require admin to install while qemu does not.
In the future, Arc will be agnostic and support multiple hypervisors. One could use qemu, VirtualBox, HyperV on Windows, kvm on Linux, etc.
At the same time I feel both excited and a bit sceptical.
This seems great because it opens a lot of possibilities.
But also has the potential to turn into another "Please download and install Adobe Flash player and refresh the page in order to view this content" thing.
It would be brilliant if browsers supported this natively (but then, I doubt IE ever would).
Google's NaCl set out to solve this same problem (pretty much), but I'm beginning to think Grun's Arc might completely shadow Google's work here for many reasons, not the least of which is total flexibility of development environment (i.e. no need for a special "sdk", except to communicate with the browser).
PNaCl is a liberally-licensed open source project. You can see its source code and compile it whenever you want. How much more open would you like it to be?
Native Client also supports the execution of nexe modules directly in the browser. However, since nexes contain architecture-specific machine code, they are not allowed to be distributed on the open web—they can only be used as part of applications and extensions that are installed from the Chrome Web Store.
Could you use Docker as a backend on Linux? I feel like it would eliminate a lot of the size overhead, and be significantly easier to ship (a single static binary)
"Native apps for the browser" = it's a lie since you basically need to download a third party software on your computer ( >60MB ) which runs as a daemon (sic),it's just yet another plugin. When that thing works without any 3rd party executable let me know.
