MESSAGE
| DATE | 2003-09-03 |
| FROM | Michael Richardson
|
| SUBJECT | RE: [hangout] We Have Met the Enemy, and He is Us
|
I agree
-----Original Message-----
From: Inker, Evan [mailto:EInker-at-gam.com]
Sent: Wednesday, September 03, 2003 8:20 AM
To: 'hangout-at-nylxs.com'
Subject: [hangout] We Have Met the Enemy, and He is Us
We Have Met the Enemy, and He is Us
September 2, 2003
By: Dave Salvator
I am constantly amazed and surprised by the resourcefulness, creativity and
overall enthusiasm that abound in the Linux community. But why can't they
create something that works easily?
GPL and open source translate into a sense of ownership among Linux users.
The community effort to expand and improve the OS is amazing. But based on
my experiences, Linux is still a mixed bag - with plenty of
late-night-where's-the-nearest-hammer infuriation over stuff that just won't
work.
I recently took a second stab at putting together a Linux-based PVR/media
jukebox server system. I got further this time, but I'm still staring at a
system that just won't work.
I took my time. I read all the documentation. I diagnosed and fixed
multitudinous glitches. But instead of success, I'm sleep-deprived,
frustrated, and ready to chuck the box out the window.
It's time for the Linux world to throw the "project" concept out the window
too. Stop thinking of these development efforts as works-in-progress, and
start thinking of them as products. Not in the charging money way, but in
the "finish and ship" way. Linux applications need to just work.
Dependencies Must Go
Multimedia and Linux are often at odds with one another, and multimedia
packages such as Freevo and MythTV have a list of dependencies as long as
your right arm. And that's my first gripe: dependencies.
Apps like Red Hat's RPM are only "smart" enough to tell you that a
dependency-check failed, but won't go out and get you the bits you need. And
it often escalates geometrically: App X needs packages A, B, and C, each of
which needs another couple of packages. Before too long the whole thing
starts looking like a Ponzi scheme, only nobody's getting rich.
Solutions Are Coming: Tools like Debian's apt-get, Gentoo's emerge and
Yellow Dog's yum do a very good job of addressing this problem. They do
dependency checks up front, gather the needed bits from trusted servers, and
surprisingly, they often get your app installed.
In my PVR project I used yum and I ended up downloading dozens of packages
before finally getting MythTV to work. Or at least, I think it worked. But,
as it turns out, once I cleared the monkey bars, now I had to crawl under
the barbed wire.
MythTV needs a lot of other modules to be installed and configured,
including xmltv and MySQL. An Advanced Linux Sound Architecture (ALSA) audio
driver is recommended. So while the yum installation utility installed
almost everything, it missed the ALSA driver.
With a small amount of effort (altogether now, './configure; make; make
install') I installed the alsa-lib and alsa-utils packages, and finally got
it working on my Sound Blaster Audigy.
I wasn't so lucky with MySQL. The yum-based installation was incomplete -
and the program is so Byzantine I still haven't gotten it working right.
Yes, I know it's a heavy-duty enterprise-class database server, but where
are the graphical configuration tools?
Unfortunately, MythTV requires that MySQL be installed and working, or no
soup for you. Suffice it to say, I'm still soup-less.
DVD Playback on Linux: One good thing came of all this bit-mashing: the
mplayer media player - and all the libdvd packages - were installed
correctly, so now I can play DVD movies on my Linux system. But it's a small
consolation prize for the still-dead MythTV bits currently inhabiting my
system.
So what's the solution? How about adopting a single word-command - I suggest
"install" to compile and set-up a package. This could be done through a Bash
script.
Then the installation routine should launch a graphical configuration
utility that will help you connect all the parts necessary to make the thing
work.
Finally, this installer will tell you where it put the damned executables.
Some apps put the bits in /usr/local/. Others put them elsewhere. But
there's little consistency on this point, and dammit, there needs to be a
lot more. Windows may be the devil, but at least you can easily figure out
where an application installs itself.
Lindows Gets It Right: Companies like Lindows have had some success
leveraging Debian's apt-get to address these problems. Many Linux pros scoff
at Lindows, calling it "Linux for the AOL set," but the company is actually
making some headway.
Still, more work still needs to be done. It begins with a fairly simple
definition: an application is NOT installed unless it works as advertised.
And the installer should ensure that that all the dependent modules are
installed and actually configured correctly. The whole thing should just
work after the installation is done.
We need 'Finishers'
The Linux community -- package developers, distribution makers and driver
writers --need to understand that that theirs is a symbiotic relationship.
They need each other to be successful.
Linux continues to face challenges from all sides: Microsoft still squarely
has Linux in its cross-hairs, considering it the single biggest threat to
continued success.. SCO is waging a proxy war against Linux while
simultaneously shaking IBM down for cash - scaring many companies away from
Linux in the process. Linux needs a more consumer-friendly OS to help to
shore up its somewhat shaky desktop foundation.
Not Dumbed Down, But Smartened Up: I'm not proposing that we dumb down
Linux. I'm not proposing that we bury code behind some curtain that no one
can see. I'm just asking that Linux application developers think their
projects through from A to Z, with Z representing a polished product that
installs successfully with minimal fuss.
We're part-way there, but like many Linux packages themselves, the most
sweat-equity goes into getting that last 10% right. If developers don't feel
compelled to finish their applications, then we need a new group of
developers - I'll call them "finishers" - to get the job done.
I enjoy a good puzzle as much as the next guy, but that's what a Rubik's
Cube is for (they're making a comeback, you know). My Rubik's Cube should be
puzzling. My Linux application installation should just work.
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
****************************************************************************
____________________________
NYLXS: New Yorker Free Software Users Scene
Fair Use -
because it's either fair use or useless....
NYLXS is a trademark of NYLXS, Inc
____________________________
NYLXS: New Yorker Free Software Users Scene
Fair Use -
because it's either fair use or useless....
NYLXS is a trademark of NYLXS, Inc
|
|
