Re: rc and smf
> - 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
--
討論串 (同標題文章)
完整討論串 (本文為第 42 之 53 篇)：