stuntmouse

He makes good points about video codecs, but it's nonsensical to imply that a 486 could handle anything like modern Flash usage.

Wow. That is not even close to being a legitimate poll.

Godspeed.

In another post, he describes his method: http://www.publicstatic.net/2010/04/migrate-intranet-applica...

[edit] grammar

guess this kills my nacl port.

$100,383 @ 10:02 AM PST.

One obvious disadvantage: with Kickstarter, you're ploppping your business plan on the net at a very early stage. Makes it quite easy to poach.

As a final note, there's no reason why the two couldn't be used in tandem. In fact, they should be.

This looks impressive for systems that are supported (Vista and up). I'm not entirely convinced that all attack vectors have been considered though.

They appear to have considered the obvious things: write and execute access to files and other resources from restricted processes, preventing harmful windows message behavior.

But would a process with low integrity have read access to every other resource with low integrity? Or is that further constrained by some other access control mechanism? Also, I don't think it's a feature for an unprivileged process to have registry access, though I understand there may be reasons for it.

It could also be argued that there is a larger attack surface for protected mode processes, because they can call any OS function, but are just denied when they don't have the access level to commit the action.

I must admit I am behind the times with regards to Windows system programming.

Very informative link. Thank you.

That's pretty vague. How does it apply to this situation?

The code is open; part of the NaCL API is designed around Posix/Linux; the Plugin API is the familiar NPAPI and its extensions.

Which part is proprietary or controlled by Google?

To my mind, some more relevant questions are: Does this tie the web to x86 (and ARM)? Can it be adapted securely to x86-64? Can it be made secure? Can multiple implementations be made secure?

Well, as wmf said, sandboxing is key. All NativeClient apps are compiled specially and scanned before they are run to ensure that apps can't use just any system call - they must interact only through NaCl's posix like library and the plugin api.

Their homepage has a paper and video describing this in detail: http://code.google.com/p/nativeclient/

[edit] Just realized I didn't respond to the meat of your post. Theoretically, there is no reason why any warning would be necessary for running a NaCl plugin because the sandboxing would be secure.

How does ActiveX sandboxing work?

As far as I know, it mainly relies on signatures. What happens when you trust a control that has a bug which overwrites your hard disk? And that's leaving out malicious code...

It is open source, and could be adapted by any browser, AFAIK.

Done right, this will change the world. I'm currently working on porting an emulator. The major sticking point so far is the audio API, which seems rather primitive, but should be sufficient for my needs.

Right, he didn't benefit at all from running his business in California for years. Why should he give back his fair share when he has the resources to dodge it?

An "oversight" for four months? On a critical part of your business that has a direct impact on the perception of the quality of the blogs you host? Are you trying to become the Facebook of blogging (in a bad way)?

You have a nice service, but this is too much. Also, it prompted me to take another look at your terms of service, which are surprisingly onerous. You've lost a user and an advocate. Good luck.

I'm excited by MacRuby's architecture and performance, but can anyone comment on how extensive and usable the HotCocoa bindings are?

You can write native Cocoa apps with MacRuby that have Mac Look and Feel, with better than acceptable performance.

There are clean, high-level Ruby wrappings of UIKit classes, see HotCocoa: http://macruby.com/hotcocoa.html, although it's not clear to me how extensive this part of MacRuby is.

It'd be interesting to pressure Adobe on this point right now, given the context.

I've also been thinking about this lately. Flash and related products are only a small part of a not very large company, relatively speaking. Why can't Google or Apple just make a deal for Flash/Flex? It's clear that the web (and mobile web) is critical for both.

A nice compliment to Visor. I wish it played better with Safari's download window though.

I should have been more specific. I'd like to change the background color of the active window to indicate which one has focus.

Your solution changes the background color for all windows.

I assumed that point was about the lack of support for plugins in Mobile Safari, though I could be mistaken.

Addendum: It looks like Cocoa-bindings are alive and well for Ruby and Python. Only the official Apple Java bridge has been phased out.

This is something I'm struggling with right now. Setting aside iPad and iPhone for a second...

Counterpoint in favor of Apple:

Contributions to an open web: Open source development of Webkit and now Webkit2, HTML5 Canvas, Adverserial stance towards Flash in favor of HTML5 [iPad, iPhone]

Contributions to open-source tools: LLVM and CLang, MacRuby support, launchd, Cocoa bindings from other languages [possibly phased out?]

Contributions to open-source operating systems: OpenDarwin http://www.opensource.apple.com/

Developer ease: Nice set of installed developer applications, Development environment based on standard opensource toolchain, Compiling command-line tools from Linux/BSDs is sane and easy, Compiling X11 dependent apps is possible

Multi-platform support: BootCamp, The only system capable of running the three major desktop operating systems easily and legally.

High quality, hackable GUI environment and applications: Cocoa applications are generally built to a far higher standard than Linux GUI applications IMO, Cocoa applications are imminently hackable (see SIMBL)

Hardware innovation and quality: Forward thinking innovation in hardware: Mac Air, for example, gets rid of even ethernet!, MacBook Pro line widely acknowledged as top-tier development machine

[Disclosure: I have no stake in Apple.]

That's probably the point. It should work with Google's compatibility layer.

for mac, i like gitx, but i wish it had built-in diffing.

Safari 4.0.5: 115/160

Mirror?