interesting article, for all those who think Ubuntu is already easy

Cefiar cef at optus.net
Thu May 25 09:19:01 BST 2006


On Thursday 25 May 2006 17:54, Scott James Remnant wrote:
> Actually this bug _has_ been fixed; in dapper, DMA is enabled by default
> for every drive and controller that we know won't let the magic smoke
> escape.
>
> For those verrry few drives that it isn't enabled, I do NOT think we
> should be giving people an option to break their machine.
>
> If it's not working for you, then can you let us know what the bug# you
> filed when you first noticed was?

I think what is really needed here is a (somewhat) simple troubleshooting tool 
that an end user can run that checks various things on the system, and tells 
the user that it suspects the system isn't running optimally for some type of 
operation (eg: DMA isn't turned on for some reason on the DVD drive, so video 
playback is impaired). This would give the user concise information to figure 
out what the hell is going on, allow a decent bug report (possibly even 
automating part of it!), and eventually the problem could be easily fixed 
without a lot of guesswork. Automating the process down to a few steps would 
encourage more people to log their problems, hopefully allowing them to be 
sorted out once and for all.

What would be really good is if this sort of thing could be scripted, so that 
an updated script/database could be installed at a later date, adding new 
troubleshooting information as it's figured out and identified.

Once such a tool is in place, it's just a matter of making users aware of it, 
and possibly integrating some way to start it into other apps somehow (eg: 
under the help tab perhaps?).

Best bit is, if such a system becomes common enough, the apps themselves may 
adopt the system upstream (rather than one huge script/database of info 
that's sort of Ubuntu specific), allowing the developers to create their own 
troubleshooting information as well. This reduces the load on the Ubuntu 
team, and allows the developers to pass on known issues that cause problems.

And yes, I know that some apps do this sort of stuff internally, but everyone 
seems to reinvent the wheel on this. They build in specific tests into their 
app, which in itself can be a problem when interfaces and the like change or 
aren't anticipated.

I must admit I'd be amazed if the idea of building a troubleshooting framework 
hasn't already been brought up somewhere before. Anyone?

-- 
 Stuart Young - aka Cefiar - cef at optus.net



More information about the sounder mailing list