[arch-general] coping with damaging updates

Mick bareman at tpg.com.au
Thu Oct 27 23:02:28 EDT 2011

On Thu, 27 Oct 2011 12:30:50 -0500
C Anthony Risinger <anthony at xtfx.me> wrote:

> the sources of error are likely not a thin smear of software that,
> imo, makes the entire experience much better and enables fine-grained
> access control ... i mean group perms are nice and all, but they are
> incredibly coarse, and over the years have forced all sorts of
> odd/convoluted application hierarchies + access patterns to cope.
> unfortunately, error sources are probably human, ie. stuff isn't
> being launched/ran/used properly.
Its not easy for the user to keep up-to-date with the stream of changes
that pour in until one day you update and a deprecated method is busted.

A thought that just occurred to me is for these kind of updates to be
segregated so that you can see them and research the procedures needed
to implement them safely.

> > Also reminds me of this morning's xorg-xdm bug report I wrote which
> > made dbus on a system level necessary, all of a sudden... Things go
> > on like this and I'll remove my Xorg and run frambuffer only from
> > now on. :-)
> doubtful ;-).  im a professional sysadmin too ATM (though, i'm 
> traditionally an applications developer, and am trying my hand at
> larger scale administration), and honestly, i'd like to see dbus and
> other tools that enhance
> discovery/transparency/communication/free-time embed themselves like
> a tick in everything possible.
this would be fantastic EXCEPT a lot of the new inclusions break
things, hence this thread.


More information about the arch-general mailing list