Re: Forth as an operating system

Keith H Duggar wrote:
And will this team ever make a mistake? And if they do,
what can happen under a cooperative task manager? Suppose
a bug makes it past review and testing into a production
system. Suppose that bug results in failure to yield. What
happens?

Ok, let's rephrase the question: Under a preemtive multitasker, you probably
need semaphores you don't for a cooperative multitasker (because in the
cooperative multitasker, everything between two PAUSEs is atomic).
Semaphores have the problem of deadlocks, and if you forget them, race
conditions are possible. Suppose your team B introduces a deadlock or race
condition. What happens? Or what happens on a memory leak?

One way around is to add some watchdog functionality. A watchdog can kill
and restart an application that fails to yield or deadlocks. An out of
memory killer can help with memory leaks (by restarting the worst
offender). This all has nothing to do with cooperative or preemptive; if
you let bugs like this happen, you must take counter-actions as described.
You can do nothing against race conditions, since there's no automatic to
detect them.

There's another problem, that's memory protection. Memory protection is
nice, since you can shield applications from each others. So at least you
know when an application breaks, it must have either been buggy from start,
or it had corrupted its own memory. Unfortunately, an application
corrupting its own memory is already bad enough. To make a system reliable
and secure, no application is permitted to corrupt its own memory. Once you
allow students and idiots to run their own selection of programs (which
then become mission critical), game over, you lost.

The bottom line of this is that people try to shield programs even more.
Virtualization is the buzzword of the year. It's actually a consolidation,
since people have put each service onto another box to shield all the
broken services from each others.

I think there are two different schools at work here. The conventional
school identifies typical bug sources and then tries to automatically
prevent them, by adding complexity on every level (hardware, OS, compiler).
The Forth school knows about the typical bug sources, but does not try to
prevent them by adding complexity, because complexity is perceived as an
evil of its own.

There are other, similar differences. E.g. how to deal with idiots who
participate in a computer programming team. The Forth school advice: Don't
let idiots touch the program code, maybe they can perform tests or talk to
idiotic customers (but don't give them any influence into technical
decisions).

The common advice however is: Use tools that let even idiots write programs.
As a consequence, the good programmers are dumbed and slowed down, and as
additional task, they also have to interface with idiotic parts of the
program (idiots neither write good interfaces nor good programs). Using the
good programmers up to write the interfaces and define the architecture
only is of limited help, since idiots can't make good use of a nicely
defined interface or architectures, either, and even good programmers tend
to write bad interfaces/architectures if they don't implement the code
behind, as well.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
.

Relevant Pages

  • Re: Forth as an operating system
    ... Suppose that bug results in failure to yield. ... Or what happens on a memory leak? ... E.g. how to deal with idiots who ... best programmers, or the programmers who are clueless about what a ...
    (comp.lang.forth)
  • Re: Guido rethinking removal of cmp from sort method
    ... has a bug in it. ... More memory yes; take longer to sort, almost certainly not (except, ... that otherwise would have been put in the cmp function, ... So far I have one actual use-case: Guido's example of sorting a huge list ...
    (comp.lang.python)
  • Re: MyString Class
    ... > I compiled your program and run it under the debugger. ... > The first crash happens in ... ... > memory is flawed. ... First bug fixed. ...
    (comp.lang.cpp)
  • Re: Please help!
    ... This bug check is issued if paged memory is accessed ... installation of a faulty device driver, system service, or BIOS. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Error: "IRQL_NOT_LESS_EQUAL" help
    ... This bug check is issued if paged memory is accessed when the IRQL is too high. ... If you encounter bug check 0xA while upgrading to a later version of Microsoft® Windows®, this error might be caused by a device driver, a system service, a virus scanner, or a backup tool that is incompatible with the new version. ...
    (microsoft.public.windowsxp.help_and_support)