Adobe, You're Killing Me Tue, Apr 14. 2009
Adobe, your Flash Player and Acrobat Reader products are complete and utter crap. I don't use other platforms enough to know or care, but the Linux versions are utterly, terrifyingly awful.
Adobe [Acrobat] Reader
- Available in several package formats. Not available from a repository, from which updates could easily be pushed to your customers; instead, we're invited to "Receive up-to-date information about new releases and security updates by registering your copy of Adobe Reader". How? "Please contact me via the following methods: (please check one or more): Mail / E-mail / Telephone". I'd much rather receive the security update and a phone call about the security update, thanks. Update: Gideon Mayhak noted in comments that AdobeReader is available in the same repository as the Flash Player. Somehow I missed that, Adobe -- probably because you make no mention of it on your website.
- The print dialog, which is fairly significant in a document reader, doesn't look like any other print dialog I've seen in a long, long time. Actually, a lot of the Reader user interface is non-standard (or perhaps just ancient?), but the print dialog takes the cake. Adobe, you made it up; it certainly isn't close to the standard Gnome or KDE print dialogs. It's a hideous monstrosity reminiscent of Motif dialogs from 20 years ago. But you do let people fiddle with the printer command line -- excellent for kiosk applications!
- When used as a plugin, Reader will consume 100% of CPU and ever-increasing amounts of memory when I close a browser tab containing the plugin. That's right: when there is no visible sign that the software is running, it's bringing the system to its knees.
- Reader does not uninstall cleanly. When AdbeRdr is removed from a system, the default handler for PDF files should revert to the pre-Adobe-Reader value, but it does not -- the system will forever look for the non-existant 'acroread' binary. I haven't yet figured out where the ghost lives.
Adobe Flash Player
- Available from a repository. Nice touch! But 64-bits, anyone?
- Consumes massive amounts of CPU time when apparently doing nothing. By massive, I mean that it pushes the CPU temperature up until the fans switch into the turbo near-ultrasonic range. I mean that it brings normally-responsive multi-user systems to their knees. I mean it uses so much electricity that environmentalists weep publicly and small furry creatures pack their bags and move to other continents, if they haven't lost their sanity because of the ultrasonic whine.
- 32- vs. 64-bit issues: don't get me started.
#1 - Gideon "Gnafu" Mayhak said:
2009-04-14 22:06 - (Reply)
Adobe Acrobat Reader is actually available from the same repository as Adobe Flash Player. Otherwise, I agree with everything else you have to say.
I would also like to add that, since 64-bit Flash does not play nice with nspluginwrapper, Reader's plugin cannot be used on a 64-bit system in tandem. I would like to see either a 64-bit Reader plugin or a 64-bit Flash plugin that plays nice with nspluginwrapper.
#2 - Stephen Carter said:
2009-04-14 23:39 - (Reply)
Oh man, I totally agree, especially about abode reader. The Linux version of reader is just so bad that there are not enough words to describe how much it sucks. To make matters worse (or is that better?) there are many good replacements for adobe reader on Linux, and at least one of them will be installed by default in any sane Linux distro. In fact, document viewer (evince) is, I believe, part of gnome. Now there is a good piece of software: clean, unobtrusive, and does exactly what you need it to do, no more, no less.
Seriously, there is no reason to install adobe reader for Linux, ever.
#2.1 - Chris Tyler 2009-04-14 23:45 - (Reply)
I agree -- except for filling in forms. If you have to fill in a Canadian passport application or T4 PDF, Evince and friends are not up to the task yet. But Real Soon Now...
#3 - Natxo Asenjo 2009-04-15 01:18 - (Reply)
There is a 64 bit flash plugin for linux: http://labs.adobe.com/technologies/flashplayer10/ (2nd hit on google of flash 64 bit). It works.
#3.1 - Chris Tyler 2009-04-15 08:13 - (Reply)
"It works" -- Yes, but unfortunately it doesn't install come packaged, doesn't install from a repository, has been months in pre-release status, and has been reported to conflict with nspluginwrapper (which is necessary to run 32-bit Adobe Reader in a 64-bit browser).
If you're in any way serious about distributing software these days, you have to take care of these issues.
#3.1.1 - Natxo Asenjo 2009-04-15 09:48 - (Reply)
Well, your point was, and allow me quoting:
"Adobe Flash Player
* Available from a repository. Nice touch! But 64-bits, anyone?"
They have an official 64 bit plugin. It's in their lab site, they give you instructions on how to install it. What else do you want? There is no 64 bit plugin for windows, read their FAQ regarding questions over that :-); sorry, but I cannot agree with you on that point. Finally a company listens to the linux users and gives them what they have asked for a long time (a 64 bit plugin for the flash player). You should be glad they have listened to the community instead.
Damned they do, damned if they don't.
But: why don't you install firefox for i386? All the plugins will work then. You just use a 32 bit browser, so what, big deal.
#3.1.1.1 - Kevin Kofler said:
2009-04-15 21:47 - (Reply)
The 64-bit plugin is not even in their repository for stupid political reasons ("hey, it's a prerelease") ignoring any sort of practicality.
And they haven't given us what we're asking for: making Flash Free Software!
Just say "no". Use Gnash or Swfdec or boycott Flash content entirely.
#5 - Anand Singh 2009-04-15 12:27 - (Reply)
Are you serious? Since when are software developers responsible for maintaining distro repos? Do Evince devs maintain distro repos? Do Okular or kpdf devs maintain distro repos? For that matter do the Gnome team or the kernel devs maintain distro repos?
In summary, you don't like Adobe because they maintain somewhat inconsistent repos while no one else maintains repos, and because they don't have 64-bit flash even though they do.
With regard to the print dialog, yes it's ugly, but it has critical functionality not available in gtk or qt. That's the reason many of us use acroread; so we can actually print pdfs. Opensource pdf readers aren't quite there yet.
#5.1 - Chris Tyler 2009-04-15 15:57 - (Reply)
"Since when are software developers responsible for maintaining distro repos?" -> Well, Adobe is not just a bunch of software developers, it's a company that is distributing software. Using a repo is The Right Way(tm) to distribute software. But if you're delivering an alpha/beta version of the software (as their 64-bit flash player), why wouldn't you also distribute that via a repository so you could update users to the final version when it's released? Obviously, someone on staff knows how to make RPMs and run 'createrepo', and once you've figured it out it takes just seconds-to-minutes to run the script whenever needed from then on.
Gnome print dialogs have a tab-based design to accommodate additional options such as those provided by AcroRead. There's no reason to reinvent the wheel, and there's no way that GLabels (for example) should have a completely unique and non-standard print dialog because it has label-specific print options (reverse L-to-R, print outlines, start at label #_).
#5.1.1 - Anand Singh 2009-04-15 19:34 - (Reply)
I don't think treating Adobe as a special case because it's a large software company makes sense. Red Hat is a huge software company and doesn't provide repos for many distros (that example was tongue-in-cheek, but the same is true for IBM, SAP/Oracle, etc...). It should be up to each distribution and its community to package software. A repository is the right way to install software when there are package dependencies. It also has the benefit of simplifying software installation. Acroread has several lang packs available, that's why it has a repo. It's also supported by Adobe, as is 32-bit Flash. 64-bit flash is not supported, and it doesn't make sense for Adobe to create a "rawhide" repo for one package with no dependencies. I would compare the situation to VirtualBox or Cedega. Both products have very good support for a broad array of distros, but again, no repos are needed since they have no specific dependencies that aren't already covered. Installing a repo for one piece of software does not simplify installation for the user, so with no dependencies to solve and adding an extra step to the installation process, what have we gained? Some distros have included these pieces of software in their own repositories.
I concede that gtkprintunixdialog can be made to accommodate the current functionality of acroread, but acroread is a direct port of a Windows app. Even the OS X version has a very similar print dialog. Also, I think implementing the realtime preview in gtkprintunixdialog would be far from trivial, making a Linux port of Acrobat Reader far less feasible (i.e.: more trouble than it's worth). In a sense, Adobe is doing what you suggest by not reinventing the wheel. They are supporting a single functionality set across multiple platforms by reusing as much existing code as possible. Unfortunately, not reinventing the wheel is bad news for the Gnome HIG in this case. Maybe QT4/GTK3 will solve that.
I'm no Adobe fanboi, it just saddens me to see one of the few companies who recognizes the Linux userbase (Linux was the first platform to get 64-bit Flash!) chastised for its efforts.
#5.1.1.1 - Kevin Kofler said:
2009-04-15 22:07 - (Reply)
> It should be up to each distribution and its community to package software.
They can't. Adobe's license forbids all sorts of redistribution including packaging. Only few distros (such as RHEL) have special agreements with Adobe (probably a paid license arrangement) allowing them to even redistribute the binaries (not modify, mind you, just redistribute and package Adobe's binaries).
Their licensing is as stupid and uncooperative as it can get.
> 64-bit flash is not supported,
That's a stupid political reason, ignoring all practical and technical reasons for publishing a proper RPM.
> and it doesn't make sense for Adobe to create a "rawhide" repo for one package with no dependencies.
There are dependencies, they're just not declared because their crappy binary tarball is not an RPM.
You're also forgetting another reason why repositories are useful: automatically getting updates. This is especially useful for prerelease software, which tends to be updated very often.
> I concede that gtkprintunixdialog can be made to accommodate the current functionality of acroread, but acroread is a direct port of a Windows app.
That's kinda the problem, a crappy port of a Window$ app which doesn't use standard GNU/Linux dialogs is not a good way to support GNU/Linux. That said, that print dialog looks horribly out of place even on Window$.
> Also, I think implementing the realtime preview in gtkprintunixdialog would be far from trivial,
Then they should just drop that instead of shipping a prehistoric dialog.
> I'm no Adobe fanboi, it just saddens me to see one of the few companies who recognizes the Linux userbase (Linux was the first platform to get 64-bit Flash!) chastised for its efforts.
If they actually recognized the GNU/Linux userbase, they'd release their software as Free Software, not binary-only crap which can't even be redistributed.
#5.1.1.1.1 - Anand Singh 2009-04-16 00:48 - (Reply)
Wow... I'm... wow.
Here's a link to the distribution agreement/license.
http://www.adobe.com/products/clients/all_agreement.html
The most pertinent part to this discussion is section "2.1 License":
"... Adobe grants Distributor a non-exclusive, non-transferable, worldwide, royalty-free license to reproduce and distribute the Software, in all cases solely for the complete installation and use of the unmodified Software on the Authorized Operating Systems..."
I remember when Linux users were the ones fighting FUD. I'm sorry if I've caused this discussion to degenerate.
Keep up the good work with the blog, Chris.
#5.1.1.1.1.1 - Kevin Kofler said:
2009-04-16 23:48 - (Reply)
Here's what the very agreement you're quoting is saying:
> This agreement is effective against Adobe only if Distributor has provided
> Adobe with information about its intended distribution and Adobe has confirmed
> its acceptance of this agreement in writing to Distributor.
and
> Distributor will distribute only the version of the Software (with its
> corresponding installer) provided to Distributor by Adobe upon completion of
> this agreement for use on the specific Authorized Operating System listed in
> Exhibit A. Distributor will not distribute any version of the Software found
> elsewhere, including on www.Adobe.com, www.Macromedia.com, or any other
> download site on the Internet.
In other words, this is not a general redistribution license, you have to sign a contract (this agreement), tell Adobe exactly what you want to bundle their software with and they have to "confirm their acceptance" (i.e. they can reject your request without even giving a reason, they can just ignore it entirely).
The agreement is also non-transferable, which can be interpreted to even forbid mirroring. There's no clause covering mirroring at all in their contract.
You're also forced to always ship the latest version (within at most 6 months, fewer if you happen to release a new version of your distribution, and this also affects all your older, still supported versions), even if it requires newer libraries than your distribution provides (RHEL had to include a special newer GTK+ in a separate directory just for Adobe Reader):
> (b) New Versions. Upon release of a new version of the Software by Adobe,
> Distributor will cease all reproduction and distribution of the previous
> version of the Software upon the earlier of (i) the next release of the
> product or service with which Distributor bundles the Software, or (ii) six
> (6) months from the date Adobe makes such new version of the Software
> commercially available. As used in this section, “new version” means a major
> new release of the Software. Adobe may notify Distributor when new versions
> are released.
In addition, there's this outrageous clause:
> Distributor may not combine an Adobe Runtime with Distributor Product or
> Distributor Service in such a way that the Distributor Product's or
> Distributor Service’s own file format or data type replaces the file format
> or data type for the Adobe Runtime. For example, Flash Player and Shockwave
> Player must always remain the default players for their respective file
> formats and data types in the browser and Adobe AIR must remain the default
> runtime for its file formats and data types (i.e., .air and .airi) on the
> desktop.
which outright bans distributing Flash if you want to make Gnash or Swfdec the default, and I guess (even though it's not explicitly given as an example) even bans shipping Adobe Reader if you make Okular or Evince the default as they should be in any sane distribution.
So this agreement is completely unacceptable for many distributions. (And of course, it isn't anywhere near Free Software, so e.g. Fedora will never ship it.)
#5.1.1.1.1.2 - Kevin Kofler said:
2009-04-16 23:53 - (Reply)
Oh, and I forgot: As you can also read in the paragraphs I quoted, you cannot distribute the binaries on Adobe's websites (so those really are non-redistributable), you have to wait for them to give you a special redistributable version. And I'm fairly sure those redistributable versions don't include e.g. 64-bit Flash, or any other thing they consider "alpha" or "beta" or just don't want you to redistribute for whatever reason (which they don't even have to tell you).
#5.1.2 - Kevin Kofler said:
2009-04-15 22:13 - (Reply)
> Using a repo is The Right Way(tm) to distribute software.
Not really. Releasing source code under a Free Software license and letting the distros package it is. (But yes, even a binary-only repo would be better than the crappy binary tarball they're dumping 64-bit Flash into, without even letting others package it legally.)
> Gnome print dialogs have a tab-based design to accommodate additional options such as those provided by AcroRead.
So do KDE print dialogs, by the way.
#6 - Patrick 2009-04-15 13:28 - (Reply)
A fix for the memory issue can be found here:
http://davelargo.blogspot.com/2009/04/having-problems-with-acrobat-reader-91.html
#7 - Peter 2009-04-16 03:34 - (Reply)
I do not use reader so I don't have an opinion, but I have one regarding Flash player - it is evil when it comes to power usage. This is why everyone I know use flash blocker and greasemonkey scripts to overwrite the video sharing web pages like youtube and so on to remove the embedded flash and embed video object to be played with mplayer/totem/whatever you have handling video in mp4/flv - it uses less than 2% CPU against 50% and more when same thing played with flash player.
