On Mon, 4 Mar 1996, Roger Irwin wrote:
> First of all let me point out that I am one of the people who sent a
> 'personal' reply to Jeremy, mentioning crontab.
>
> It was not an idle comment.
And I did not mean to sound as though I were dismissing it. It _is_ a
good idea, and would be a central component. Read on...
[snip]
> In fact the custom code we wrote for the maintaining the system was a small
^^^^^^^^^^^
> script, which I will explain later, evrything else being done by the normal
> unix tools and facilities.
This first sentence illustrates my point. In order to _maintain_ your
kiosk you had to write your own custom code. This is in contrast to
whatever code (custom or not) that you use to actually get the job done.
The difference is that right now, anyone wanting a kiosk not only has to
write and/or integrate their primary application(s), but also a support
system that maintains the health and well-being of the computer, usefully
reports errors, etc., etc., All of these are solved problems, to one
degree or another, but each person wanting to develop their
kiosk/PDA/embedded system must integrate it himself.
What I propose is a preintegrated support system, with as much flexibility
as possible with regards to how it can be deployed. The user should be
able to mix and match the pieces (the display, the error report mechanism,
and the prerequisite/dependency check) to suit their needs, _without_
having to write custom code. This is the essence of the Unix way--we
write applications that do their jobs so well and in such a general manner
that their unmodified reuse is easy, leaving us to solve the problem we
came here to solve (e.g. the actual implementation of the kiosk).
The pieces may have to be code we come up with, but as often as possible
will be code from someone else.
> Jeremy's problem is that his way of thinking about computer systems
> has been corrupted by overexposure to the limitations and
I really take this as an insult! I come from a Unix background. I know
and understand the Unix toolbox approach. And I advocate it everywhere I
do any coding or system design. My previous messages have concerned the
_abilities_ of an embedded application shell, NOT its implementation. I
don't like giant monolithic apps. I like small, simple, 1-function little
programs. They are easier to write, easier to debug, and they force the
system designer to create real, useful, and elegant abstractions. This is
how I would implement the embedded application shell.
This idea is a shell in concept only. First, it would not be just one
single executable/script. And it wouldn't be a true Unix shell. I was
afraid it would be misinterpreted if I named it that, but it really is a
shell in concept in that it encapsulates the system, and I couldn't think
of a better name. "Launcher" came to mind, but I was afraid it didn't seem
general enough.
> its just that if you think about the items he cited in UNIX terms,
> your first thought is "so where is the problem". Let's face it,
As I said, all of these problems have been solved in a piecemeal fashion.
And they've been solved for the general case, so we would definitely take
advantage of them.
Let me ask Roger this: can you build your kiosk today without having to
write that custom script that parsed error messages and respawned
applications? If not, then could anyone use the script that you did write
for their own kiosks with no logical/program flow alterations, only a
change of configuration parameters? Does the script work for
user-interactive apps like Netscape? Does it detect when the network is
down and give useful error messages to both the user and to the sysadmin?
If the answer to these questions is "no", then I've illustrated the
problem. If the answer is "yes", well, the first question I posted on
this subject was "does anyone have code that does this?". I was asking if
anyone had such a thing. (I realize that you may not be at liberty to
release it.)
(It may well be that everyone here is happy to start from scratch for each
embedded application they write. That is fine. Then you wouldn't have a
need for what I am proposing. But I can't help but feel that such a
system would make putting Linux/Unix out into set-top boxes, web-surfing
kiosks, PDAs, etc, much easier, and this make it more attractive to both
commercial vendors and to schools and universities. A cheap, easy,
widely-used embedded shell would make life easier for a lot of people.)
[snip]
> So how **do** we do what Jeremy wants? Well, the best I can do is give
> you some tips and tricks to get you thinking in the right way, then
> you go and experiment!
And after we experiment (which I assume is what everyone here is doing),
we should pool our knowledge, then maybe (if we have time and ability)
contribute our experiences into a product for anyone to use.
[snip]
I've cut Roger's excellent implementation ideas, some of which I had
thought of (using FIFOs), some of which I hadn't (like using netpipes).
> But what about 'the whole caboodle'? What launches you apps in the
> first place, and checks up on the validity of the system as a whole?
> Well, here you write your own script (or executable or whatever),
> which to all intents and purposes constitutes your 'shell'. You should
> have realised by know that if you know how to exploit the facilities
> of UNIX (which are far more extensive than what I have sneak previewed
> here), such a shell will be simple yet powerfull and elegant, and what
> you write yourself will be far more powerfull and **easier** to create
> than having some generic mechanism that must be programmed and set by
> a plethoria of options.
This may illustrate a fundamental difference in opinion between myself and
Roger. As I understand what he writes here, he would prefer a custom
application/script rather than a generic mechanism. He maintains that it
would be more powerful and easier. I disagree that it would be more
powerful. I think a well-implemented, generic solution would be more
powerful--if it is sufficiently flexible. This is why I bring the topic
here for discussion (and I thank Roger for taking me to task, forcing me
to restate and rethink my ideas).
It is true that developing and implementing my ideas wouldn't be as easy
as writing a a custom app for a certain task. However, the point is that
if I (and anyone else interested) go to the effort of doing it (and doing
it correctly), then it makes it easier on who knows how many people who
could then use it for embedded task.
And if it is done correctly, it would be easier for them to set up and use
this shell than it would for them to write their own code. And they won't
need to "know how to exploit the facilities of UNIX". We know how, we
exploited them, and we make them easily used by others.
Writing an application that runs on bare metal is easier than writing your
own Unix kernel, userland libraries and apps, then writing your own
application. But, using the kernel, libs, and apps that someone else
wrote and just writing your own application is easier still.
> And what starts your shell? Well, when the Linux kernel has booted, it
> invokes /sbin/init. You **could** replace this with 'your_shell' but I
> would not recommend it, as there are numerous actions to be carried
I'm glad you mention this. You are right, a custom init isn't necessary.
Perhaps we'd just provide some sample special-case inittab files to be
included in the distribution that work with whatever overall architecture
we choose.
See? Someone else solved the problem and solved it well. No need to
reinvent the wheel. We would just want to "integrate" it, because we know
how. Someone only interested in putting up their kiosk or their PDA
doesn't know how, and aren't curious enough to figure out how.
> out. Anyway, init sets up the system by means of the scripts contained
> in /etc/rc.d, (which also contains the scripts init uses to shut down
Only because /etc/inittab tells it to run rc files.
> On the other hand, when we did the multi-media information kiosk we
> did not do this. We had two subsytems, one which furnished the client
> side, and one which dealt with updating the system from the server.
> Our 'shells' were simple scripts which simply ensured that the apps
> and deamons where up and running, and if they were not, re-started
> them, then exited. These scripts were invoked periodicly by crontab.
> So the apps were always started by crontab the first time it launched
> our scripts.
And functionality such as this would be an essential part many embedded
systems (ones that interacted with users, anyway).
[snip]
Issues of time granularity would certainly have to be dealt with. And at
least for now, any embedded system requiring real-time reactions probably
wouldn't benefit from this shell idea--in their case, generic solutions
are likely to have too much overhead associated with them. (RT-Linux is
really cool because its "generic solution" is as generic as possible--put
your application (almost) right on top of the bare metal. But then, you
need to do a lot more work. Its a trade-off. I don't know much about
other real time Linux solutions (like DROPS).)
I envision that most uses requiring real-time reactions are more along the
lines of sensing and controlling applications, where uses of this proposed
shell would be for applications that interact, one way or another, with
humans. This certainly isn't a hard and fast rule, just a vague guide.
> Graphics. Look long and hard at X, despite its ugly looks it is very
> sophisticated, and extremely modular. It may be invoked with no window
> manager and as such represents a full screen graphics whiteboard where
> objects may be created and manipulated from multiple programs
> simutaneously from anywhere within a TCP/IP network.
And functionality such as this would be an essential part many embedded
systems (ones that interacted with users, anyway).
[snip]
> The possibilities are endless, and if anything the access control and
[snip]
Indeed they are. The very thought of having to develop an embedded
application shell using Windows makes me cringe, because 1) all apps are
monolithic and there is no history of leveraging other people's work, and
2) I doubt one could write a shell around applications (like mail and web
clients) that could easily control them.
As a test situation, a minimal implementation of this embedded app shell
would be able to do this: With no extra coding, a competant Unix
administrator should be able to set up a Linux box and install the EAS.
The she would be able to make it an email kiosk by editing a configuration
file that says "run Mutt, keep an eye on it, make sure that the network is
up and the POP server is running". Later on, the admin can change the
configuration (again, with no code changes) so that it runs Netscape mail
in X instead of Mutt and keeps an eye on both X Windows and Netscape. No
other changes.
Thanks, Roger, for your thoughts. I hope I have made my own opinions
clear.
--Jeremy
Jeremy Impson
Network Engineer
Advanced Technologies Department
Lockheed Martin Federal Systems
[EMAIL PROTECTED]
