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