[Infowarrior] - What's So Precious About Bad Software?

Richard Forno rforno at infowarrior.org
Sat Sep 29 20:17:19 UTC 2007


What's So Precious About Bad Software?
August 24, 2007
By Carla Schroder

Carla Schroder
http://www.enterprisenetworkingplanet.com/netos/article.php/3696296

Opinion: What's the real reason for closed, proprietary code? Embarrassment.

Sure, we are drowned in tides of twaddle about precious IP, Trade Sekkrits,
Sooper Original Algorithms that must not be exposed to eyes of mere mortals,
and all manner of silly excuses. But that's all a smokescreen to cover up
the real reason: to hide code of such poor quality that even PHBs know to be
embarrassed. Exhibit A: Windows itself. Which proves it takes more than
throwing billions of dollars and thousands of programmers at a software
project to build something that is actually good.
Diebold, Champion of Ugly Bad Code

There is a good ugly code and there is bad ugly code. Good ugly code is not
"elegant", whatever that means, but it works well and isn't full of holes.
Diebold is the poster child for bad ugly code, which they have fought
mightily to conceal under the tattered "trade secrets" excuse. As if- they
were shipping shoddy code, and they knew it. I wonder where they got the
idea that no one would notice, because hiding the code doesn't hide what it
does.

Samsung's Excellent Rootkit

Number three on our hit parade is Samsung's infamous binary Linux printer
driver. Oh, that one's a knee-slapper. The installer‹ I am not making this
up‹changes the permissions on key Linux system directories, and replaces a
batch of executables with setuid wrapper scripts. setuid means ordinary
unprivileged users can run these executables with rootly powers. So
installing the Samsung printer driver comes with a fun double whammy:
screwed-up permissions and local privilege escalation! Yay! Now that's some
compact coding.

I had to see this one for myself, so I downloaded their Unified Linux Driver
and took a peek in install.sh, which fortunately is a nice human-readable
shell script. This is but a representative snippet of the badness therein:

wrap_setuid_third_party_application xsane
wrap_setuid_third_party_application xscanimage

wrap_setuid_ooo_application soffice
wrap_setuid_ooo_application swriter
wrap_setuid_ooo_application simpress
wrap_setuid_ooo_application scalc

So OpenOffice and your scanner tools launch with root privileges for
ordinary users without asking for a password. In effect, it's a built-in
rootkit. But that's not all. It also changes the owner on /etc, /usr,
/etc/sane.d/, /usr/lib/, and /usr/lib/sane/ to an unprivileged user instead
of root. That is some seriously perverse ingenuity.

Yes I know, this isn't exactly an example of bad closed source because
anyone can read the installer script. But if they're this incompetent with a
shell script, what does the driver code look like? Note also that this was
reported repeatedly to Samsung, with no fix until it hit Slashdot.
System BIOS

The x86 PC BIOS is a relic of a bygone era. You'd think something this tiny
would be easy to continually improve and modernize. But no, not at all. Even
on our shiny powerful modern hardware, the typical closed, proprietary (and
buggy and inflexible) BIOS thinks it's still supporting MS-DOS, probes
hardware, loads drivers, scans for bootable devices, initializes memory, and
allocates interrupts. Then, at last, it starts up the operating system which
ignores everything the BIOS did and starts over (both Linux and Windows do
this). A number of Linux distributions are investing resources in improving
boot times, but the BIOS alone accounts for 30-60 (mostly wasted) seconds of
boot time.

Contrast this with the OpenBIOS project, which takes a different approach.
OpenBIOS assumes the operating system is going to do the work, so all the
BIOS needs to do is get the machine to a state where the OS can take over.
The Linux kernel is a lot faster at detecting hardware and loading drivers;
it doesn't need an antique moldy BIOS getting in the way. We don't need to
see inside that little bit of code to know that it isn't pretty- the way it
functions speaks for itself.

OpenBIOS is already being used in a number of projects, such as the
LinuxBIOS, which is amazing and impressing all kinds of people with 3-second
boots and unlimited customizability.
Moldy Binaries

Way too many of the closed-source applications and drivers for Linux don't
even try to keep up. NoMachine's Linux server and client, for one example,
rely on an ancient version of libstdc++ that sends you wandering all over
Google trying to locate a copy of it. Most printer vendors don't even try:
Given a choice between vendor-supplied drivers and reverse-engineered CUPS
drivers, you're almost always better off with the CUPS drivers. Which is
pretty amazing considering how few of these have any sort of vendor support.
Closed-to-Open Horrors

When the Netscape browser code was opened up and flung upon an eager world,
it nearly caused a pandemic of heart failures because of its blue-ribbon
spaghettiness. The majority of the work in the early years of the Mozilla
project was cleaning up the mess. Same story for OpenOffice, which is
descended from StarOffice. StarOffice was originally this giant monolithic
blob; a self-contained little universe that barely needed an operating
system, because it contained its own working environment. Poor old
OpenOffice has been struggling for years to get out from under this unwieldy
architecture.

Naturally there are examples of both good and awful code in both the closed-
and open-source universes. I'm just not buying into the "protect our
preciouss IP" excuse because it is so overused. What's so precious about bad
software? 




More information about the Infowarrior mailing list