Prevent people from updates with critical components
Joachim Langenbach
joachim at falaba.de
Sat May 29 08:40:35 UTC 2010
Good Morning again,
I'm a bit stunning, that nobody seems to be interested in such a thing. Im not
afraid of coding it myself, even if I have not much time for that right now,
but I think even in that case, a discussion about the preferred way is
important.
I'm wondering about the fact of lack of interest, because, far as I know, the
goal of Ubuntu is, to make a Linux distribution for people, who aren't
famillar with computers that much. So pointed one can say, it's a linux
distribution for typical windows users. (Don't understand me wrong here, I
mean this very positive!) And concerning kubuntu, I'm such a user (normally I
use Gentoo, but on one PC I use kubuntu with the aim, to have one PC with less
administration efforts for a not so interested user). So from my point of view,
this missing feature is a great lack at the mentioned goal. It makes me
thougt-provoking that I actually think, the administration of kubuntu consumes
the same time (or may be more) as administer gentoo.
I know, that some other users of Kubuntu think the same way like I do, so I'm
still hoping, that the developers of Kubuntu may think about this problem!
Yours' sincererly,
Joachim Langenbach
On Tuesday 25 May 2010 10:05:08 you wrote:
> Good Morning all!
>
> After last release update and time consuming error repairing, I've think
> about a system, to inform users with critical system components that an
> update is not recommended at their machine.
>
> My thought was a system like the following one:
>
> 1. Provide a list of kown critical components and their problems
> 2. Check the list before update and inform the user that critical
> components are present and that the system doesn't work properly after
> update 3. If the user wants, do the update
> 4. Inform the user, if an update is present, which solves the errors
>
> To 1:
>
> It can be an XML-File like this:
>
> <CriticalComponents>
> <Component>
> <Name>Intel GMA950</Name>
> <Description>Intel Graphiccard</Description>
> <TestCommand>/usr/sbin/lspci | grep -i 950</TestCommand>
> <ErrorMsg>
> <EN>Graphical Desktop isn't working after uodate</EN>
> </ErrorMsg>
> </Component>
> </CriticalComponents>
>
> A structure like this allows to display a detailed report (if needed in
> several languages) and allows to test for nearly every hardware with help
> of TestCommand. In the case above, all TestCommand should return nothing,
> of the component is not present. So the testing mechanism is quite
> flexible and for most cases a simple call with a pipe to grep is enough to
> find a component. Another reason is, such a system would be quite easily
> to code and mantained.
>
> So I'm happy if this thougts starts a discussion about such a mechanism and
> results in any implementation of such a thing. I'm also interested if such
> a mechanism before updating is interesting for ubuntu users or not, from
> my state it is a needed feature to address people without computer
> knowledge!
>
> Yours' sincerly,
>
> Joachim Langenbach
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20100529/c672341c/attachment.sig>
More information about the Ubuntu-devel-discuss
mailing list