Re: [dwm] Re: Crash-only software

crash only... even the name sucks.

2009/2/4, markus schnalke <meillo_AT_marmaro.de>:
> [2009-02-03 22:33] Marcin Cieslak <saper_AT_system.pl>
>
> >
> > I don't like this approach. I have always preferred software that "fails
> > fast". As soon as something is wrong - just abort with debugging information
> > what went wrong.
> >
> > I see some issues with the approach described in the paper. It assumes that
> > the state saved is okay - I think that crashes occur _because_ internal
> > state is inconsistent or wrong.
>
>
> Seems as if you got a different view on the concept than me. I think
> its not so much about error handling in the first way, but about
> organizing state so that killing a software is equal to shutting it
> down.
>
>
> > Sure, you can dump internal state regularly
> > for recovery - but it's like with backups - you never know which one is
> > really clean and okay until you try to restore.
> >
> > Software bugs will sometimes create incorrect data. This may go unnoticed
> > for some longer time.
>
>
> But if you implement a crash-only design, then these problems will get
> erased. Exactly this is the sense of such a design: Have a software
> that handles these problems in a _sane_ way. Also these situations
> will be tested throughoutly as they are the _normal_ situations.
>
>
>
> > I think that authors unnecessarily assume that software components are
> > "black boxes" that need to be kept up at all costs. This is not the right
> > approach for availability I think. Most issues will occur when the component
> > is upgraded and needs to use/migrate old data or sometimes to cooperate with
> > still not upgraded components. If something goes wrong, the rollback becomes
> > the issue also - if I have new, badly-behaving components that dumped its
> > state in a new format, how do I go back?
>
>
> Of course, compatibility is an issue, but IMO an unrelated one.
>
>
>
> > Sweeping problems under the carpet is not going to help much...
>
>
> I think the crash-only approach explicitely wants to focus on the
> problems, that means actually _not_ sweeping them under the carpet.
>
>
>
> However, I know that I don't stick close to the paper. I base my
> argumentation also a lot on thoughts I made, inspired by the paper.
> Thus we might discuss from different points of view ...
>
>
> meillo
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJiV6Y6aFpZ+X9qBIRAr09AJ4kIFf4UtauYN9eMG89eHbRoZllqgCeI9cx
> LUKBeT4WnGAcADeo4q8fuAc=
> =eXr1
> -----END PGP SIGNATURE-----
>
>
>

-- 
http://www.gnuffy.org - Real Community Distro
http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy)