Hi,
Well - the latest is now out. I thought I would do something
different, and comment on the older version.
My comments - well - take them as you will..
Some have decried ubuntu for the lack of configuration tools - to change
things the way they want. Hmm.
This is "important" to some, but I see a computer as a work tool -
something to pick up and use and get the job done.
In my experience, "tweaking" the look almost invariably leads to zero
productivity improvement, and much wasted time.
Some teaks do work::decreasing the size of tool bar, adding a cpu
performance meter. To me - I am happy with the "look".
The update manager seriously annoys me. Some packages hang in the
install process, doing nothing. You have to open the extra
details, click q in the "less" process that is running and trying to
explain something, and move on. If linux is truly ready for the
masses, there should be no need for this.
Pulse annoys me. Pulse is designed around one sound device - which means
that on a laptop with an inbuilt sound card, and
usb headset, only one is operational. True - one can go into the
preferences and move the sound to the headset from the
sound card. But it is clunky. Would it not be better to make the ring
tone playable on the speaker, and the conversation on the headset.
Well - some say - you can edit asound.conf with this wonderful short
script to get sound that way with alsa. The moment you say,
"edit a system sound file", you are proving linux is not ready for the
masses.
Alsa annoys me - applications that are labelled "alsa compliant" do not
always work.. A customer asked me to write a linux app
that has 20 concurrent sound channels on it. On pulse - it runs fine. On
Alsa - well - it depends. There is now a document that
says some alsa calls are safe for application developers to use - and
others that are not safe. Going further, they say that the application
should write the sound data to the library in sizes appropriate to the
device - so some want it in 16 or 32 or 200 bytes at a time. All
applications for alsa have to do this - which means there is a whole lot
of duplicated code out there. Surely, such bundling of bytes into
the right size is best done in the library? (That is the purpose of a
library - to put common code in the one place, accessible to all).
The transition of Alsa to Pulse is the right transition - the process is
just painful. Usually hindered by the mountains of legacy alsa scripts
we have written to get sound somewhat right. Remember that the only
thing which is advanced in alsa is found in the name.
But what really bites, and really annoys, is the handling of USB
devices. This problem is also found on Fedora, so don't get excited.
I have a USB device which encodes/decodes audio (320 bytes of 8khz audio
can be turned into 49 bits). If this device is in the box, the box
is then powered on, the usb device does not respond to programming
requests. It shows up at /dev/ttyUSBx - the codec connects to linux
via a FTDI chip. To get the device to work, it has to be unplugged, and
plugged in after power up.
--turns out there are a host of other devices (usb mouse etc) out there
with a similar problem. Always - they need to be unplugged after boot,
and then plugged back in, before they will work.
Turns out that there is a thing called a modem-manager, which actively
probes all FTDI devices at startup. Yes, I wrote a program to do a
FTDI reset in an endeavour to bring it back, and copied/tried the
programs out there to reset the usb bus. None of those brought my USB
device back to life. So why don't I want to just remove the
modem-manager (responsible for mobile broadband wireless)?
Well, I could. It would be problem solved (for me). But for others who
use my program - they too would have to do the same. And some of
them are mobile people, and want the modem-manager. Instead, they all
have to remember to unplug/plug the USB device in, and then start my
program, and then start work. A process they have to go through every
time they boot their box.
Partly the problems results from multiple people using the same
vendor_id:product_id on different different devices.
Enough ranting. Maybe this can spark some activity on this list. Who
knows - I might get lucky and someone tells me how to disable the
modem-manager for a particular usb vendor/product pair.
Cheers,
Derek.
--
Derek J Smithies Ph.D.
Christchurch,
New Zealand
-- "How did you make it work??" "the usual, got everything right"
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users