Re: rc and smf

[Jonathan Dama <jd@xxxxxxxxxxx>]

> - Not everyone needs a fault-tolerant system.  Or rather, different
> people need different degrees of fault-tolerance.  Most people don't
> need telecom-level reliability.

As much I don't want to participate in this
(pointless) debate...

1) No one expects the OS to be boxed up as the swiss army
   knife of computing.  This is why packages/ports exist.

2) Fault tolerance built around a single PC-Compatible
   computer is at best pseudo tolerance.

	If in the long term, dragonfly ends up supporting a
	fault-tolerant SSI cluster architecture, such an
	achievement will be much a more significant
	improvement over the current state of affairs than
	simply revamping init.

	Do you want to fight over bandaids used to improve
	single-computer reliability or do you want to aim
	for something loftier (and in my opinion more
	interesting intellectually)?
   
3) Load-balancing, distributed firewalls, distributed
   storage solutions, database replication, etc, etc
   are all (better) solutions to this problem.
   e.g. www.rainfinity.com
   
4) If you want reliability go buy an IBM/360 based system.
   This is what you would do if you were a bank.  Did you
   know that IBM mainframes execute the same program on
   multiple processors and check that the result in both cases 
   is the same?

5) Telecom reliability is at least the silver standard of
   systems reliability.  But that is _for the most part_
   a result of the world-wide monopoly origins of the
   telecommunication community.  Honestly, do you think a
   competitive industry would really care to line the tops
   of their long-haul buried cable runs with a concrete
   blast shield to protect against nuclear detonation?

-Jon

> 
> - Many daemons implement some form of supervision themselves.  Much of
> the 'djb regime' is not actually new, it just tries to commodify
> concepts such as supervision and daemonization at the operating system
> level, rather than having every program do it themselves.
> 
> - Erlang's concurrency is typically much more fine-grained; most Erlang
> processes are not daemons in the usual sense (they only ever service
> each other rather than the outside world.)  The programming paradigm in
> this case is also different; because supervision guarantees have already
> been made, failure is "acceptable", and many processes are written in a
> "let it crash" style.  This simplifies error handling immensely in many
> cases, BUT it's most practical when working with lightweight processes
> (basically threads).  It's not nearly as effective a programming style
> when working with operating system processes.
> 
> -Chris

--