Linked by Thom Holwerda on Tue 9th May 2006 21:25 UTC, submitted by luzr
OSNews, Generic OSes Torvalds has indeed chimed in on the micro vs. monolithic kernel debate. Going all 1992, he says: "The whole 'microkernels are simpler' argument is just bull, and it is clearly shown to be bull by the fact that whenever you compare the speed of development of a microkernel and a traditional kernel, the traditional kernel wins. The whole argument that microkernels are somehow 'more secure' or 'more stable' is also total crap. The fact that each individual piece is simple and secure does not make the aggregate either simple or secure. And the argument that you can 'just reload' a failed service and not take the whole system down is equally flawed." My take: While I am not qualified to reply to Linus, there is one thing I want to say: just because it is difficult to program, does not make it the worse design.
Thread beginning with comment 123012
To view parent comment, click here.
To read all comments associated with this story, please click here.
rycamor
Member since:
2005-07-18

Thanks for the support. I've been promoting signal-based computing for over 10 years and it's only recently that I've begun to make a dent in the existing paradigm.

Is there currently *any* actual open source software demonstrating the efficacity of these concepts that I can download and toy with?

While I am not necessarily buying into your "paradigm battle", I find the concepts interesting. My interest isn't so much in the microkernel/monolithic kernel debate, but in distributed programming in general. My current project is largely signal-based, with an IPC mechanism handling communication between separate processes. Is your approach intended only for low-level programming, such as kernels, or would it apply to any sort of software development?

If the end result of your 10+ years of effort is just a series of theoretical papers and conceptual drawings, with no actual working software, I have to remain skeptical. However, giving the benefit of the doubt, would it be possible to implement a working model of your ideas given a set of modules and an IPC mechanism in some scripting language, such as Python, Ruby, or even PHP? What page of your website would be the best starting point for this?

Honestly, this whole discussion of signal-based computing seems quite reminiscent of the dicussions in Functional programming (although FP does not explicitly use signals, the effect seems similar, as are the claims to "software correctness"). The main difference being that the functional programming guys actually have tons of working software out there. What are the parallels and differences between your concepts and those of the functional programming (eg. the Lisp machine)?

Reply Parent Score: 2

axilmar Member since:
2006-03-20

Honestly, this whole discussion of signal-based computing seems quite reminiscent of the dicussions in Functional programming (although FP does not explicitly use signals, the effect seems similar, as are the claims to "software correctness"). The main difference being that the functional programming guys actually have tons of working software out there. What are the parallels and differences between your concepts and those of the functional programming (eg. the Lisp machine)?

Signal-based programming is reactive programming: code is invoked when a state change is detected.

Functional programming is the exact opposite: there is no state, only computations. Values are copied with each change, and special constructs called monads are used to make sure memory space is reused and operations are invoked sequentially.

You may consider signal-based programming as event-driven programming where code can be attached to any variable. I have posted an example of a phonebook application at

http://www.rebelscience.org/phpBB2/viewtopic.php?t=33

where anyone interested in signal-based programming can discuss it there.

Personally I found signal-based programming much easier than anything else, but it has to be used together with functional programming; some aspects of FP are very useful (like combinatorial programming), some others are not that useful (like making the sequence of computations irrelevant - nobody things without sequencing in mind), and some others are plain irritating (like not being able to update state - not all state update is bad; plus there is no useful FP program without monads anyway).

Reply Parent Score: 1

Mapou Member since:
2006-05-09

If the end result of your 10+ years of effort is just a series of theoretical papers and conceptual drawings, with no actual working software, I have to remain skeptical. However, giving the benefit of the doubt, would it be possible to implement a working model of your ideas given a set of modules and an IPC mechanism in some scripting language, such as Python, Ruby, or even PHP? What page of your website would be the best starting point for this?

As I mention elsewhere, there are already working reactive languages out there, e.g., Esterel, Signal, etc... Project COSA goes much further down to the elementary instruction level. My idea is that COSA should be a graphical environment because software is represented more like a logic circuit. Also, it is easier to get gestalt of a complex program using simple icons. I haven't done any programming on COSA other than a neural network that I use for my AI research (which takes most of my time). I would be happy to work full time on a COSA OS/virtual-machine and dev studio if I could secure enough funds.

As far as distributed computing is concerned, the COSA model is ideal since all elements in COSA are concurrent. However, since COSA is synchronous, in order to get the full promise of reliable code in a multiprocessor system some way would have tobe found to synchronize the various processes. That said, COSA does not prohibit asynchronous processes since it also supports message-passing via queues.

Reply Parent Score: 1

Cloudy Member since:
2006-02-15

However, since COSA is synchronous, in order to get the full promise of reliable code in a multiprocessor system some way would have tobe found to synchronize the various processes.

This, of course, is the boundary at which all attempts to do pure synchronous programming fall down: when they meet the asynchronous nature of the real world.

Anyone who has ever designed mixed-signal integrated circuits will easily understand why.

Reply Parent Score: 1

Mapou Member since:
2006-05-09

This, of course, is the boundary at which all attempts to do pure synchronous programming fall down: when they meet the asynchronous nature of the real world.

Not true. The real world is both synchronous and reactive. All reactions are synchronized by a universal clock because the fundamental interval (at the Planck level) is the same for all processes/interactions. The universe is ONE, as its name implies.

Reply Parent Score: 2

beyert Member since:
2006-05-10

> Honestly, this whole discussion of signal-based
> computing seems quite reminiscent of the dicussions
> in Functional programming (although FP does not
> explicitly use signals, the effect seems similar, as
> are the claims to "software correctness"). The main
> difference being that the functional programming guys
> actually have tons of working software out there. What
> are the parallels and differences between your
> concepts and those of the functional programming (eg.
> the Lisp machine)?

"signal based" programming is not related to functional
programming, but rather object-oriented programming
(what he says sounds like message passing programming
to me), while functions should always be valid
messages, they aren't stateful in fp, so his "reactive"
paradigm is based on explicit use of side effects.

Furthermore, as you stated, (and in my personal
experience) functional programming has real software
to show it's merits, even when it isn't purely
functional, or is written in "impure" langauges such
as scheme and sml, as referential transparency on
various levels of the program makes it much easier to
reason about the code.

I hope that fp advocates don't appear dogmatic, because
many of the benefits are very practical and result in
code that is pleasant for me to read.

I should also note that most Lisp advocates advocate
dynamic programming and code=data much more strongly
than functional programming. (not that either are
contradictory with functional programming, the language
Joy has all three qualities) From the common lisp code
that I have seen, most use state extensively throughout
the program (though it is not difficult to write
functional code in the language). In the case of
Scheme, there is a lot more functional code written
in it, but it isn't purely functional either.

Similarly, it is quite possible to write functional
code in most garbage-collected languages, such as Perl
and Python. "Higher Order Perl" is a good resource for
perlers.

Edited 2006-05-10 22:50

Reply Parent Score: 1