Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Jun 2007 19:39:30 -0700
From:      Modulok <modulok@gmail.com>
To:        kzabbo@bellsouth.net
Cc:        questions@freebsd.org
Subject:   Re: FreeBSD and Robotics
Message-ID:  <64c038660706171939s6651c3a0vd0e52b2e25c5069d@mail.gmail.com>
In-Reply-To: <20070617222805.TPDE28395.ibm60aec.bellsouth.net@mail.bellsouth.net>
References:  <20070617222805.TPDE28395.ibm60aec.bellsouth.net@mail.bellsouth.net>

next in thread | previous in thread | raw e-mail | index | archive | help
It's only as good as the drivers you write to control the robot. It
also depends on just how critical your "critical situations" refers
to.

In situations where human life is directly dependent upon the
integrity of the system, a modular kernel design has traditionally
been preferred over the monolithic kernel designs found in Windows,
Linux, BSD. That isn't to say that FreeBSD is unstable, in fact it's
very stable. However, in a situation where people die if the system
fails, there are some questions as to the safety of the underlying
designs of these kernels. The reason for this is, (in general), device
drivers operate in the kernel's memory space and therefore have the
potential to bring down the rest of the system, should they fail,
(again, in general). In a modular kernel design, where everything is
run in user-space, if a single driver goes berserk it is entirely
insulated from the rest of the system.

Then there are embedded systems, which are regarded as more stable
because the hardware they run on is identical from one system to the
next and never changes. Contrast this to operating systems that must
run on a wide range of consumer hardware; there is a statistically
higher probability of mistakes, just due to the increased size of the
codebase. (In practice this doesn't always work out though, as I've
used some embedded systems that were embarrassingly unstable). The
smaller codebase of embedded systems and modular kernels is typically
easier to audit, as there is far less code. Where human life is
directly dependent, the code must be audited by a third party.

For pretty much any other "critical application", FreeBSD Release has
been quite stable in my experience. Strip the kernel of everything you
don't need, write good drivers and run it all on stable hardware and
you should be fine in most situations. You'll probably go years
between reboots.

Just my 2 cents.
-Modulok-

On 6/17/07, kzabbo@bellsouth.net <kzabbo@bellsouth.net> wrote:
> I've read some really good things about FreeBSD, especially its virus
> resistance and reliability.
>
> Will FreeBSD work on a robot that has to be trusted in critical situations?
>
> Kevin
>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64c038660706171939s6651c3a0vd0e52b2e25c5069d>