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