Letters to the editor

Three (more) things that need fixing for Linux to work on the desktop

 
Yesterday I tried to listen to a radio station over streaming audio
that happens to only broadcast in an adjacent province. The
procedure on an Apple or Windows box is as simple as doing a
double-click on the URL. Under RedHat, I assumed that my expertise
(i.e. rute.2038bug.com) would be sufficient. Here is the procedure:
 
    1. Right click on the URL to copy the link location
    2. Do a google search to try figure out what kind of
        Free application would play this. Mplayer seemed like
        the thing.
    3. Read through the install guide and download three
        rpm files.
    4. Installed only to discover they had bad signatures.
    5. Read through the rpm man page to learn how to turn
        off signature checking.
    6. One of the rpm's was corrupted. Rpmfind.net revealed
        an alternative copy.
    7. Try to install again, but now it seems I need the SDL
        library >= 1.1.7
    8. Located, downloaded and installed libSDL 1.1.7.
    9. SDL library needs to be over version .so.1.2
    10. located the latest SDL library, downloaded, and
        installed.
    11. Install mplayer rpm's with the --nosignature option
    12. Read the mplayer man page.
    13. Run mplayer with mms://<site>:8080 as required.
    14. mplayer says something about its cache and sits
        there for 10 minutes producing no sound.
    15. Check my sound modules, run aumix, and test that
        sound is working fine with,
            play /usr/share/sounds/KDE_Beep_Beep.wav
    16. Search mplayer man page for anything about "cache"ing
    17. Run mplayer with a smaller cache option.
    18. Mplayer says "ASF file format detected" ...
        "Cannot find codec for audio format 0xA."
    19. In the mplayer FAQ section under "2.1.2.4. WMA/ASF files"
        there is no text, and the mailing list archives do not
        have much about it.
 
I mean no disrespect to the Mplayer developers: they have done a
truly outstanding job. This is a systemic problem to do with
proprietary-ness of formats. It is also simply a matter of fact
that: on an Apple or Windows machine I simply double-click, whereas
on Linux, I spend over four hours fiddling, and still cannot listen
to this really nice radio station.
 
The industry will *always* be coming out with new formats,
hardware, and protocols. How is the Free software community
going to keep up?
 
I had the identical problem with a Logitech camera (although with a
bit of kernel hacking I managed to get it to work: 16+ hours later).
An HP USB scanner I bought I could not get working (unsupported by
Sane: 2 hours) and resorted to installing Windows just to scan stuff
in (1 hour install, 30 minutes to get the scanning working).
 
Most of the sites *I* visit work perfectly under either Konqueror,
Mozilla or Opera; BUT most of the sites my trancing 16-year-old
cousin visits are completely unreadable with anything except IE.
They have so much javascript, flash, audio, etc. they don't even
come up at all.
 
Any company that is considering donating money to "Open Source"
needs to have a serious look at these issues above any others. It is
insufficient to look at Linux "on-the-desktop" from the perspective
of an Emacs user. A critical mass of users is surely going to
require such basic features as I have described.
 
And I haven't even got started discussing the deficiencies in
OpenOffice *sigh*. Stay tuned....
 
-paul
 

Comments (10 posted)

I *want* linux support but *not* support requiring a GUI.

In the old days on linux 0.99pl13 and the like, buggy hardware was often
deemed to "work" even if it did not work with linux---for evidence it
did not work I use mess-dos. Every time the hardware proved broken in M$
DOS too. Now can you say it does not work in linux and not get laughed
at 98% of the time. This is an improvement.
 
However the UPS example shows how limited and clueless vendor support
is. Programming information should be provided too. A windows style UPS
control application is *useless* on the servers I would want to protect,
which do not have X11 or anyone logged in and are not going to get
either just for a UPS.
 
Instead I want a small *non GUI* scriptable solution that can be relied
upon to shut my system down cleanly when the power outage requires it.
There have been times when I tried the vendor solution and not was it
unsuitable but also did not work. Fortunately there was a free, light
weight small, appropriate alternative piece of software for that UPS
(made by APC, I think).
 
Hopefully vendors will get the clue about that serious un*x servers,
especially paranoid firewalls and embedded boxen, do not do users or
GUIs eventually. My servers usually do not have a web admin interface
either---instead I use root shells via an ssh connection (and, in
extremis, 80x24 text mode on the console). For an audit trail all have a
log book which *should* record all authorised changes, symptoms and
steps taken to solve a problem.

Comments (3 posted)

Page editor: Jonathan Corbet