Re: coping with damaging updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Thu, 27 Oct 2011 12:30:50 -0500
C Anthony Risinger <anthony@xxxxxxx> 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.

mick


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux