Proprietary Slopware can't uninstall itself properly
Homer
all known from day one that Windows completely lacks any proper package
management, and sloppy uninstalls are endemic on that platform,
typically leaving behind a slew of garbage in that abomination called
the Registry, and in seemingly random and arbitrary locations all over
the filesystem. Indeed it actually seems impossible to uninstall certain
components at /all/ under Windows, third-party or otherwise. I've
previously mentioned Nero Scout, and certain versions of Windows Media
Player; DirectX and Internet Explorer, for example.
But here we have a Linux application packaged in RPM format, that cannot
uninstall itself properly, leaving behind (just like Windows) a slew of
crap all over the filesystem, and worse yet, failing to leave the system
in the same state in which it found it (again, just like Windows),
actually damaging system and user configurations to the point that the
system becomes unusable, until extensive diagnosis and manual correction
has been performed.
This is where the argument that "proprietary = professional = better"
completely falls flat, since there is absolutely nothing "professional"
about the utter garbage that I've just spent the last few hours battling
with.
I'm referring to Adobe Reader for Linux version 8.1.2, which is provided
as proprietary freeware in an RPM package.
I recently decided to compare features and PDF rendering on three PDF
viewers, Adobe Reader; Evince and KPDF. As it turns out, all three are
pretty comparable, other than the fact that Adobe Reader is somewhat
slow; bloated; and (as I later discovered) has a badly broken uninstall
RPM script. Adobe Reader also seems to have a problem with certain
embedded images for some reason, as printing those affected documents
from Adobe Reader produces solid black boxes instead of the embedded
image. It renders the image OK to the screen though. I have no idea what
the problem is, and as it's a proprietary application it's unlikely that
I ever will. There has also been quite a few security and privacy
concerns over using Adobe's proprietary software, again something that
users are powerless to do anything about, beyond vetoing that kind of
software.
It's when it comes to uninstalling Adobe Reader that the "fun" really
starts though. The first clue that something went wrong was when the
"rpm -e" command took an inordinate amount of time to complete,
certainly longer than I expected. As I later discovered, this was due to
the "%post" scripts that formed part of the package, which are executed
"post" uninstall, ostensibly to restore the system configuration to its
previous state. What these scripts /actually/ did was completely wipe
out the system MIME settings for PDF, requiring me to manually restore
them using RPM and KDE Control Centre:
http://forum.fedoraforum.org/printthread.php?t=181598
I then discovered that Firefox was unable to handle PDF files correctly
too, since the Adobe RPM had failed to clean up garbage it left behind
in the plugins directory (nppdf.so). Even then, I still had to force the
plugin cache to refresh, by deleting ~/.mozilla/firefox/pluginreg.dat
before I could finally download PDF files again using Firefox.
What a bloody mess, and all thanks to Adobe's non-standard and broken
RPM of their proprietary Slopware.
Is anyone still confused about why I advocate keeping the Windows
paradigm as far away from Linux as possible? As IBM's Bob Sutor recently
said; "Stop copying Windows". This mess from Adobe is just one of the
many reason why. The "Windows way" of doing things is not only broken,
but is /mysteriously/ broken in ways that cannot be addressed by the
user - beyond trial and error, and even then the best one can hope for
is a workaround rather than an actual solution. That makes it not only
broken, but actually dangerous.
--
K.
http://slated.org
.----
| By bucking Microsoft for open source, says Gunderloy, "I'm no
| longer contributing to the eventual death of programming."
| ~ http://www.linux.com/feature/142083
`----
Fedora release 8 (Werewolf) on sky, running kernel 2.6.23.8-63.fc8
16:45:55 up 233 days, 13:21, 3 users, load average: 2.45, 1.59, 1.26
Linonut
> This is where the argument that "proprietary = professional = better"
> completely falls flat, since there is absolutely nothing "professional"
> about the utter garbage that I've just spent the last few hours battling
> with.
>
> I'm referring to Adobe Reader for Linux version 8.1.2, which is provided
> as proprietary freeware in an RPM package.
>
> I recently decided to compare features and PDF rendering on three PDF
> viewers, Adobe Reader; Evince and KPDF. As it turns out, all three are
> pretty comparable, other than the fact that Adobe Reader is somewhat
> slow; bloated; and (as I later discovered) has a badly broken uninstall
> RPM script.
acroread is /very/ slow and bloated, though it has been quite awhile
since I've installed it because of its bloat.
> It's when it comes to uninstalling Adobe Reader that the "fun" really
> starts though. The first clue that something went wrong was when the
> "rpm -e" command took an inordinate amount of time to complete,
> certainly longer than I expected. As I later discovered, this was due to
> the "%post" scripts that formed part of the package, which are executed
> "post" uninstall, ostensibly to restore the system configuration to its
> previous state. What these scripts /actually/ did was completely wipe
> out the system MIME settings for PDF, requiring me to manually restore
> them using RPM and KDE Control Centre:
>
> http://forum.fedoraforum.org/printthread.php?t=181598
>
> I then discovered that Firefox was unable to handle PDF files correctly
> too, since the Adobe RPM had failed to clean up garbage it left behind
> in the plugins directory (nppdf.so). Even then, I still had to force the
> plugin cache to refresh, by deleting ~/.mozilla/firefox/pluginreg.dat
> before I could finally download PDF files again using Firefox.
>
> What a bloody mess, and all thanks to Adobe's non-standard and broken
> RPM of their proprietary Slopware.
It's amazing how many commercial vendors just don't take the time to get
it right.
> Is anyone still confused about why I advocate keeping the Windows
> paradigm as far away from Linux as possible? As IBM's Bob Sutor recently
> said; "Stop copying Windows". This mess from Adobe is just one of the
> many reason why. The "Windows way" of doing things is not only broken,
> but is /mysteriously/ broken in ways that cannot be addressed by the
> user - beyond trial and error, and even then the best one can hope for
> is a workaround rather than an actual solution. That makes it not only
> broken, but actually dangerous.
I'd go even further, and be wary of any proprietary vendor glomming onto
Linux.
They're welcome to produce software for Linux, but they'd better do it
right.
--
Nice guys finish last.
-- Leo Durocher
Roy Schestowitz
Hash: SHA1
____/ Homer on Sunday 10 August 2008 15:46 : \____
They try to simplify this to the point of ignoring package managers and using
the same practices that GPU makers, Automatix and companies like Sony do to
ruin one's system. Google Earth, I suspect, is a similar bugger that assume a
one-click intall trumps all (I last installed it about 2 years ago, so it may
have changed).
I installed Adobe Reader just 2 days ago. I needed it to export as text an ISO
document that was leaked to me and KPDF cannot do selection as far as I can
tell (and yes... I could have gone with Evince which is on my repo but I
didn't and I even SSH's to another faculty in order to just use proprietary
junk without installing it on my system). Anyway, my experience so far on
Mandriva has been good. I have not tried /un/intalling the software, but I did
download it at very high speed (just a few seconds) from Adobe, double-clicked
it (put the password in) and voila! It was installed. Even file associations
were in tact and there was no need to restart the session. There was quite a
big EULA to click OK on, though.
Hiding complexity to simplify may also mean hiding a lot of mess. Not "mess" as
in complexity but "mess" as in "your system is being messed up". No wonder
Windows is wiped and reinstalled so often. No wonder so little software is
compatible with Windows Vista. Ugly hacks cannot be carried through.
- --
~~ Best of wishes
Roy S. Schestowitz | "Turn up the jukebox and tell me a lie"
http://Schestowitz.com | RHAT Linux | PGP-Key: 0x74572E8E
18:05:02 up 20 days, 4:11, 3 users, load average: 1.02, 0.98, 0.83
http://iuron.com - Open Source knowledge engine project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkifMAYACgkQU4xAY3RXLo61FgCgjtRVvVbGurI3S3tUWk+NNGXf
gkoAnjYIDlVdi71LSAWEU5L2xx+8FGKI
=YJDq
-----END PGP SIGNATURE-----
7
I normally quarantine crap like that if I had to on a virtual machine.
With dual core PC and Linux being so efficient,
there is hardly anything that can't run properly.
If it can't do its job (too many CPU cycles for starters,
unauthorised net activity, creeks the system to dead slow,
or just plain crap because it doesn't live up to its marketing),
the unholy crap never gets used further than that hurdle.
There are plenty of alternatives, and time is too precious to
waste on WINDUMMY crap, WINDUMMY pedigree thats been
coverted for Linux in a WINDUMMY way, and the proprietory crap
that hides all its subversive activities.
Rex Ballard
> * Homer peremptorily fired off this memo:
>
> > This is where the argument that "proprietary = professional = better"
> > completely falls flat, since there is absolutely nothing "professional"
> > about the utter garbage that I've just spent the last few hours battling
> > with.
I remember in 2000, shortly after everybody started breathing because
computer systems didn't shoot nuclear missles from outer space due to
the Y2K bugs, there was suddenly a glut of Windows and COBOL
programmers who wanted to get the jobs as Web Developers.
Many of them were able to learn Java, or even Unix and C and C++, but
they also brought their bad habits and Windows-limited thinking with
them. They could not grasp the concept that Unix didn't need to
resort to massive multi-threading to get performance, that a fork()
was sufficient. The result was that there were some hideous Java and
Unix based server projects that were being programmed just like
Windows projects, and having exactly the same problems Windows had.
I have seen similar problems when Windows desktop applications are
converted to Java and/or OSS APIs. The developers try to put the
grapes and yeast into the wine-skins and wondering why they don't get
the wonderful performance of Linux/Unix. Even OS/X had some first
release "transition pains" as developers learned to adapt to the
capabilities of Linux/Unix and Java.
There are fundamental differences that go all the way back to the
roots of both systems back in the 1980s.
UNIX, especially BSD 4.2 and later, were multiuser systems. The
operating system had to mediate all shared resources, and the kernel
was specifically designed to minimize the contention between resources
and processes, including foreground and background user shells.
Shared resources were accessed by sending requests to servers, often
via UDP or via message queues. Message queues had been used by IBM
since the late 1960s, also to mitigate the contention between
resources. There were also Unix domain sockets, which provided memory-
to-memory connections to servers for access to shared resources
ranging from simple file "databases" to complex servers like DNS and
X11.
As a result, there was very little need to focus on these lower level
details, and developers could focus on functionality and
presentation. For most of the UNIX community, the goal was to serve
as many users as possible, as efficiently as possible. Even when
users used X11 servers and client applications, everything was
designed to be efficient and clean, with the GUI interface generating
a series of "transactions" or "streams" which could be parsed by
servers, and streams sent back to the GUI interfaces to provide near-
real-time response and accuracy. This is why UNIX was used for real-
time sensitive information such as stock tickers, investor news feeds,
and monitoring systems for everything from telephone switching systems
and electrical switching grids to Nuclear reactors and transportation
systems including railroads, air traffic, and even automobile traffic,
in real-time. This gave Unix equipped users the ability to rapidly
respond to sudden changes with instinctive real-time accuracy and
speed, avoiding potential crisis situations with sometimes split-
second reactions.
Furthermore, with servers such as X11, it was possible to create
interesting complex applications by simply combining a set of simple
applications into X11 "Frames".
In Microsoft world, the operating system did as little as possible,
and the developers managed everything within their process, and they
were limited to a very small number of "processes" including the
"Terminate and Stay Resident" (TSR) processes. The application
managed it's own memory, and some applications such as Lotus 1-2-3 and
Borland SideKick even had their own multitasking. Some applications
even used overlays and swapping.
Over the years, Microsoft would incorporate more and more of these
application developer designed functions into MS-DOS and later
Windows. At the same time, Microsoft focused on the features that
would give them the biggest "Bang for the Buck" in the single-user
desktop environment. As a result, things like preemptive
multitasking, effecient memory management, high speed context
switching, and security were very low on the priority list, while
things like really pretty Icons, wizards, and carefully orchestrated
GUI interfaces such as those found on Word, Excel, PowerPoint, and
Project were carefully designed to be just slightly better than those
of WordPerfect, Lotus 1-2-3, and Corel Draw, but only just enough
better to seduce users into dropping the established competitors, and
switch to the Microsoft products, after which, there was very little
further effort applied.
As a result, most Microsoft applications had to have all functionality
combined into a single process. EVERYTHING had o be compiled or
linked into that single process, including help, initialization,
exception handling, and of course, the interaction between threads
within that process. Of course, the applications could make use of
shared libraries, called Dynamic Link Libraries (DLL), but even those
had to be carefully managed because many of the classes and methods
were not fully reentrant, so the application had to manage the
interactions with these classes to prevent race conditions and
deadlocks.
Eventually, Windows and UNIX experienced a fusion into what we now
call the Internet or the World Wide Web and Web 2.0. With Windows
clients being interfaced to UNIX servers, using a client/server or
client/middleware/server interface in which forms were transformed
into requests to the server. The server then send back a response
which could the be displayed by the GUI interface. Some of these
interfaces include Web Browsers, E-mail readers, Instant Messaging,
and even charting and streaming video.
Of course, to do this, many of the interfaces had to be "Dumbed Down"
for Windows. For example, the Web couldn't handle full-blown SGML at
the time, so the UNIX community came up with a minimalist subset we
now know as HTML. Linux and Unix could handle far more complex
interactions and documents using REAL SGML, but Windows would just
crash if it tried. Eventually, a comprimise between SGML andn HTML was
adopted called XML, which allowed the use of very simple SAX parsers
or the more complex DOM parsers, but even the SAX parsers were "Dumbed
down" for Windows.
Instant Messaging actually started on UNIX as "Talk" and allowed to
UNIX users on the same server to "talk" to each other, even though
they might be in different offices, different floors, different
buildings, or eve different cities. Later, Internet Relay Chat
provided the ability to connect to public servers and interact with
lots of people who would join "team rooms". You could enter a team
room, ask some questions, and someone would "whisper" and invite you
to a private chat, where you could get your questions answered. It
became a popular hangout for UNIX and Linux administrators. Later, an
LDAP directory was used to help identify who was on, and provide each
user with the ability to make cheir own "buddy list". The early Linux
implementations kept the two functions separate, with the ability to
"whisper" to someone who might not even be in a chat room at that
moment.
The Windows version had to be dumbed down because the client had to
support both the LDAP directory and the IRC functionality in a single
process. And again, all of the help, exception handling, and other
"house-keeping" functions had to be compiled into the applications.
> > I'm referring to Adobe Reader for Linux version 8.1.2, which is provided
> > as proprietary freeware in an RPM package.
Adobe is a Vendor who has mostly written Windows and Mac clients for
almost 20 years. Acrobat was Windows based for many years, and didn't
even come in a Unix or Linux flavor. Unix users had ghostscript and
gzip or bzip, which could provide compressed postscript that could
easily be displayed to Linux/Unix GUI users. There is even a pdf
rendering tool which makes use of simpler processes, and has been
"good enough" for quite some time.
Many Windows application vendors go through some "adjustment pain"
when making the transition to Linux/Unix. Many things they had to
manually code into the application process are already available as
fully functional processes. Other things can often be done more
efficiently, and many of the help and exception handling fuctions can
be moved to other processes entirely, and invoked only when they are
really needed.
> > I recently decided to compare features and PDF rendering on three PDF
> > viewers, Adobe Reader; Evince and KPDF. As it turns out, all three are
> > pretty comparable, other than the fact that Adobe Reader is somewhat
> > slow; bloated; and (as I later discovered) has a badly broken uninstall
> > RPM script.
>
> acroread is /very/ slow and bloated, though it has been quite awhile
> since I've installed it because of its bloat.
For the reasons I just explained above, this is understandable.
Eventually, Adobe will find the people with the skill set to optimize
applications for Linux/Unix (including Mac), and they will stop trying
to "Fight" the operating system. Remember, when applications start
trying to write their own memory "heap" managers, they end up fighting
the memory management system of the kernel. Suddenly memory has to be
mapped, remapped, and each remapping requires context switches and
other conflicts. Allocating object pools, and letting the kernel map
the memory from it's pool of large or small buffers will allow the
kernel to optimize the memory use and mapping, including the passing
of buffers between processes in the form of interprocess
communications.
> > It's when it comes to uninstalling Adobe Reader that the "fun" really
> > starts though. The first clue that something went wrong was when the
> > "rpm -e" command took an inordinate amount of time to complete,
> > certainly longer than I expected. As I later discovered, this was due to
> > the "%post" scripts that formed part of the package, which are executed
> > "post" uninstall, ostensibly to restore the system configuration to its
> > previous state. What these scripts /actually/ did was completely wipe
> > out the system MIME settings for PDF, requiring me to manually restore
> > them using RPM and KDE Control Centre:
In a Windows context, that makes sense. If you have registry entries
pointing to non-existent DLLs and classes, some unpleasant things can
happen, from sudden termination of the application to Blue Screen of
Death. I just recently tried to install a fresh copy of Windows on a
new drive, and used a Backup/Restore utility to back up settings,
applications, and files from the old drive to a USB drive, then
restore them to the new drive. It seems that the Backup didn't copy
anything from "Program Files" and when I tried to run the "Recovered"
drive, I suddenly found a previously reliable version of Windows
giving me blue screens within as little as 15 minutes.
It seems that the only way I can reliably move this configuration from
a 5400 RPM drive to a 7200 RPM drive is to have VMWare converter
create an image, and then run Windows XP as a VMWare client. It did
give me a significant increase in speed, so it was worth the effort.
> >http://forum.fedoraforum.org/printthread.php?t=181598
>
> > I then discovered that Firefox was unable to handle PDF files correctly
> > too, since the Adobe RPM had failed to clean up garbage it left behind
> > in the plugins directory (nppdf.so). Even then, I still had to force the
> > plugin cache to refresh, by deleting ~/.mozilla/firefox/pluginreg.dat
> > before I could finally download PDF files again using Firefox.
Again, this makes sense. FireFox doesn't depend as heavily on a
"registry" which means that if Adobe searches the registry
(Xrdb, .Xdefaults and app-defaults in the case of Linux/Unix), it
won't find the FireFox configuration contexts.
> > What a bloody mess, and all thanks to Adobe's non-standard and broken
> > RPM of their proprietary Slopware.
I wouldn't be too hard on Adobe. Many people like having Acrobat to
read PDF files, and their relative success with Acrobat gave them
enough courage to do the Flash port too.
It will take some time for Adobe to "find it's way around" on Linux,
and to learn to do things the "Linux Way". It sounds like FireFox
might want to look at doing a sync of it's configuration files with
the X11 configuration files as well. Simply putting the properties
in .Xdefaults provides the user-level configuration control desired.
> It's amazing how many commercial vendors just don't take the time to get
> it right.
It even took IBM a few years to get it right. Look at some of their
Lotus Notes solution attempts. It's a good study in what NOT to do.
Notes 8 is a good example of how to do it right.