The Adobe Flash Player Deadlock
(Update: see Adobe Does Not Suck for an update on these criticisms.)
I don’t use proprietary software very often; one of the few pieces of proprietary software that I do use with some frequency is the proprietary Adobe Flash Player plugin. On a daily basis, it reminds me why I try to avoid proprietary software in the first place.
One illustrative point: I’m sure most people who have used the plugin on Linux experienced occasional browser lockups when exiting a page which used Flash. I experience it frequently, and everyone I’ve asked has had the same issue. It’s been a problem with the 9.0 releases of the plugin for a long time, but Adobe’s never done anything about it. Either they don’t know, or they don’t care.
I can’t rule out not knowing. I’d love to report the bug, but Adobe doesn’t provide an obvious way to do that without going through their “complimentary product support” channels—which require a registered Adobe product. All I want to do is put in a PR! Most open source projects are more receptive to bug reports (and that isn’t saying much).
Of course, if I did put in a PR I couldn’t really be more specific than
“the flash player sometimes deadlocks when tearing down a plugin instance,
locking up the entire browser.” I don’t have the source available to me
to examine the issue in any more detail, and the EULA I agreed to when
installing the plugin is rather stringent about reverse-engineering, so
it’s not like I could legitimately go in with gdb to see what the deal
is either.
This is hardly the only annoyance, either. Non-IA32 platforms have been left in the dust for a long time, and in recent revisions of the 9.0 plugin for Linux, there’s at least an additional livelock, worsening memory leaks, and severe performance regressions in the video pipeline. (Incidentally, if you’re having memory problems with Firefox, try removing the Flash plugin and see the kind of difference it makes.)
If the Flash plugin were open source and the worst issues had remained unresolved for this long, I’d try to resolve some of them myself. I’ve got a decent amount of experience with concurrent programming, and more likely than not the issues are fairly straightforward. This is not because I feel any special obligation to Adobe to do their work for them. I’d be doing this for my own sake, and for the sake of the other people who have to deal with this stuff all the time.
Adobe’s decision to open source their Tamarin JavaScript runtime had me hopeful that they would eventually also open source the Flash runtime (at least just the plugin), but their more recent decision to incorporate DRM into Flash is discouraging. They could still open source the non-DRM portions, but most likely my only hope for an open source Flash plugin is something like Gnash—which I can’t safely contribute to now that I’ve agreed to Adobe’s EULA for the proprietary plugin. In the long term the DRM decision is also likely to cut open source players off at the knees since their ability to play the most popular Flash content will be strictly limited. If Adobe isn’t going to give us an open platform to play Flash content, nobody else can either—is that it? Beacuse that’s the appearance it gives. You get it from Adobe, or not at all—and there’s an awful lot that Adobe simply isn’t providing.Thanks Adobe; you’ve managed to alienate another developer. I’m going to stick to authoring software and content for platforms whose vendors don’t play these kinds of stupid control games, so I don’t lock my own users into your twisted little world. Sun’s entirely open platform is looking much better these days, and they’ve finally got people working to address the gross deficiencies of Java applets that gave Flash its opening in the first place. I’ve done Flash development in the past—the reason Flash dominates right now is not because it’s great platform to use and develop for, but rather only because the alternatives have been so much worse. That circumstance is, thankfully, beginning to change.