Linux-Development-Sys Digest #140, Volume #7 Thu, 2 Sep 99 02:13:45 EDT
Contents:
Re: Jesus: the ultimate OS ("Christopher R. Thompson")
Re: TAO: the ultimate OS (Christopher Browne)
Re: Linux on RS/6000 (Peter Samuelson)
Re: TAO: the ultimate OS (Christopher Browne)
Re: select() and FD_SETSIZE (H. Peter Anvin)
Re: TAO: the ultimate OS (Christopher Browne)
gdb Reference ([EMAIL PROTECTED])
Re: The optimization debate (was: why not C++?) (Christopher Browne)
Re: understanding scheduling in Linux (Peter Samuelson)
Re: Linux on RS/6000 (Peter Samuelson)
Re: select() and FD_SETSIZE (David Schwartz)
Re: TAO: the ultimate OS (Christopher B. Browne)
History (Julius)
Re: select() and FD_SETSIZE (Kaz Kylheku)
Re: gdb Reference ([EMAIL PROTECTED])
register_chrdev returns ok, but doesn't register anything! (nick nelissen)
Re: Linux on RS/6000 (Magnus Larsson)
Re: select() and FD_SETSIZE (Phil Howard)
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
----------------------------------------------------------------------------
From: "Christopher R. Thompson" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: Wed, 01 Sep 1999 16:16:13 -0700
Pizzi wrote:
>
> >Where is it in the bible that jesus had sex?
> It isn't in the Bible that Jesus had sex.
>
> >Why didn't he?
How do we know that he didn't? If we were not given the information
either way then it must be imaterial and irrelevant.
> Well, Buddhists and hard-core Christians see sex as submission to your
> physical body's drives.
What ever happened to "be fruitfull and multiply"? Why was it not "get
married be fruitfull and multiply".
>
> hope some of this made some kind of sense, (and man are we off-topic)
> - Ed Pizzi
Possibly: I was thinking about how any of this might apply to the
pro-creation of "Linux: The Operating System". Should we apply the same
constraints. No downloading 'til your properly married. Imagine the
chaos if we allowed "bastard" Linux's to populate the world. Thank God
Linus is a proper father, and Linux the well behaved child.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Sep 1999 01:41:03 GMT
[As always, redirected to comp.os.research, as this is neither
discussing UNIX nor Linux...]
On Tue, 31 Aug 1999 13:13:09 +0000, James Andrews
<[EMAIL PROTECTED]> wrote:
>I'm sorry, I'm as skeptical as the next guy, but I'm afraid you're just
>being spiteful, for this reason, I think I'll sit and probe the errors
>of your logic for a change, give Vladimir a break. I can abide flaming
>or dissent for a thread, but this one seemed a little lacking in the
>foundations... ok, where shall we start...
>> You wouldn't be able to access a filesystem anyway because you have to
>> make it impossible to open a file! Of course, these are all blind
>> assumptions-- I don't actually know anything about this sandbox concept
>
>So why are you arguing? I think arguing with a point you dont
>understand, or claim to know anything about is blatant stupidity. Why
>make blind assumptions?
Indeed. Both of you are missing one of the critical points of his OS
design:
It doesn't have a filesystem, because that's a Silly Nonuserfriendly
Computer-oriented Feature.
It is designed to use persistent objects instead.
..So if you're going to criticize the sandbox scheme, you have to
base it on the security scheme (that has not been described) for
management of persistent objects.
Mind you, Theodor Nelson was highly critical of the use of files back
in 1973 (Dream Machines/Computer Lib), and we haven't yet gotten to a
fundamentally better way of organizing data yet, some 26 years later.
[Note that the 1987 edition of Computer Lib adds in a discussion that
the "way to go" for security might well be to look at "capabilities."
When ESR was quoted a few weeks back in InfoWorld as suggesting that
EROS, a capabilities-based OS, might be the successor to Linux, it's
entirely fair to say that Nelson was there 12 years earlier...]
--
Replying to one's own message is a rarely-exposed technique for
switching positions once you have thought about something only after
sending mail.
-- from the Symbolics Guidelines for Sending Mail
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/linuxkernel.html>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: 1 Sep 1999 19:20:21 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[<[EMAIL PROTECTED]>]
> Well, take a look at:
> http://users.snip.net/~gbooker/as400.htm
Hmmm, he says he wants to target the older AS/400's and in any case the
page gives off the distinct flavor of a pipe dream. I was referring to
the PowerPC-based AS/400's....
I do like one quote: "The AS/400 is noteworthy for being the most
proprietary widely used computer system." Not necessarily accurate; I
would vote for the older m68k Macintosh line, with its own networking
standard, its own GUI widget set in ROM, its own OS (rather incestuous
with the ROM graphics widgets, of course), its own busses, its own
builtin graphics hardware and even builtin monitor. The only really
cross-platform-standard feature seemed to be the SCSI bus.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Sep 1999 01:45:53 GMT
Followups, as always, redirected to newsgroups that are more relevant
than those speaking of UNIX or Linux...
On 1 Sep 1999 20:02:19 GMT, Vladimir Z. Nuri
<[EMAIL PROTECTED]> wrote:
>In comp.os.misc Theodore Y. Ts'o <[EMAIL PROTECTED]> wrote:
>: Indeed, and sandboxes aren't new either, and even predate Java.
>
>the general principle imho has not been fully/adequately
>explored.
A meaningful discussion would likely mention such things as:
a) Capabilities, and
b) Virtual Machines.
Neither are particularly new; both have been "in production" to one
degree or another on IBM mainframes for the better part of twenty
years.
--
"...Deep Hack Mode--that mysterious and frightening state of
consciousness where Mortal Users fear to tread." -- Matt Welsh
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: select() and FD_SETSIZE
Date: 2 Sep 1999 00:45:24 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED]
In newsgroup: comp.os.linux.development.system
>
> The problem is that the size argument is brain-damaged. If you want
> to select on descriptors 256 through 511, you have to specify 512
> as the size, even though the first 256 descriptors are ignored.
>
> Allocating the fd_set is cheap because when it is done in automatic storage.
> Allocating automatic storage is done on the stack simply by moving the stack
> pointer. The fixed size of the object actually helps you there; if it were
> variable, you would have to use dynamic allocation or some hack like
> alloca().
>
Actually, gcc allows automatic allocation of arrays of dynamic size.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Sep 1999 01:45:54 GMT
On 1 Sep 1999 13:43:27 -0700, Graffiti <[EMAIL PROTECTED]> wrote:
>In article <7qk0ob$[EMAIL PROTECTED]>,
>Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>>yes, that is exactly what I am proposing: a system in which all
>>applications run in a sandbox-- even key elements such as drivers.
>>I believe this is not only desirable but inevitable.
>
>So you're basically using a microkernel with each service in its own
>server, and each application running in a VM?
<read with a really fey accent>
That's just such a *technical* way to put it... Just too
computer-oriented to be considered user-friendly. We need to express
this in terms that would be familiar to Lao-Tze...
</read with a really fey accent>
>>let us agree on this then: the problems will not go away unless the
>>sandbox is designed in an ingenious way that transcends all prior
>>attempts lacking in imagination.
>
>Let's not.
It certainly seems to transcend *something.* I think what it is
transcending is primarily someone's ability to do basic research...
--
Rules of the Evil Overlord #31. "No matter how well it would perform, I
will never construct any sort of machinery which is completely
indestructible except for one small and virtually inaccessible
vulnerable spot."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED]
Subject: gdb Reference
Date: Thu, 02 Sep 1999 01:40:43 GMT
Does anyone know where "Using GDB: A Guide to the GNU Source- Level
Debugger, Richard M. Stallman and Roland H. Pesch, July 1991." is
posted on the WEB?
Thansk!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: The optimization debate (was: why not C++?)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Sep 1999 01:41:36 GMT
On 1 Sep 1999 16:25:26 GMT, William Burrow <[EMAIL PROTECTED]> wrote:
>On Wed, 01 Sep 1999 04:19:11 GMT,
>Stephen E. Halpin <[EMAIL PROTECTED]> wrote:
>>On Tue, 31 Aug 1999 02:18:04 GMT, [EMAIL PROTECTED] (Christopher Browne)
>>wrote:
>>>Once optimized once, it's harder to optimize the code again.
>>
>>If this werent true, all processes would converge to O(1),
>>and all data sets would compress to a single bit. Ultimately
>>there is a minimum amount of work that has to be done to
>>perform every task, and you cant optimize a process beyond
>>that minimum. Its not unusual or unexpected for this bound
>>to be approached asymptotically. Outside a particular context,
>>you cant generalize this to imply when any optimization may be
>>made to have the best chance to achieve that minimum, and
>>indeed, poor system design can prevent later optimizations
>>from being effective without redesigning the whole system.
>
>Wow, ten lines that basically repeats what was said in one line. Only
>on USENET. ;)
...And I'm typically the one that gets accused of being
long-winded...
--
Een schip op het strand is een baken in zee.
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: understanding scheduling in Linux
Date: 1 Sep 1999 20:41:31 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Surya P Kommareddy <[EMAIL PROTECTED]>]
> > I am beginning to program modules under Linux (version 2.0.36). I
> > would like to know some pointers to information on the scheduling
> > implimentation
[Kaz Kylheku <[EMAIL PROTECTED]>]
> Read kernel/sched.c
Good answer ... but would I appear bigoted if I expressed my doubt that
the answer was satisfactory to someone who posted from Outlook Express?
(:
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: 1 Sep 1999 20:38:58 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[BSD Bob <[EMAIL PROTECTED]>]
> Any chance something like that would run on an old 7012/220 machine?
Nope. They only support the latest 'n' greatest, i.e. PowerPC chip,
CHRP motherboard, PCI bus, Open Firmware. I don't know what the 7012's
are but I doubt they're any of the above, except maybe PowerPC.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: select() and FD_SETSIZE
Date: Wed, 01 Sep 1999 19:57:38 -0700
"H. Peter Anvin" wrote:
> fd_sets are the real problem, not select(). Whereas select() takes a
> size argument, most people just allocate a fixed-size array, in the
> form of fd_set. This is where the design broke.
It's not just what "most people" do. It is the only thing you are
allowed to do. There is no requirement that 'select' use bit masks and
no requirement that the bits work a certain way. Everyone who calls
select either uses fixed-sized arrays or does something non-portable and
not guaranteed to work.
Since there is no portable way to determine the size of an fd_set,
'select' is never guaranteed to work under any circumstances. There is
no guarantee that '8*sizeof(fd_set)' has any special meaning. There is
no guarantee that every file descriptor you can open can be selected on.
There is no guarantee that 'getfdtablesize' will tell you anything that
has any correlation to 'select'.
Worse, if you exceed the size of an fd_set, you will likely cause data
corruption or crashes. The fd_set macros generally don't check range. So
you can never safely use any of the fd_set macros or select. It is the
most horribly broken UNIX function I know of. I *never* use it when
'poll' is available.
DS
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Sep 1999 02:42:27 GMT
On 1 Sep 1999 19:56:34 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]>
posted:
>In comp.os.misc Peter T. Breuer <[EMAIL PROTECTED]> wrote:
>
>: C'mon folks, don't be dense. He means a virtual unix provided to the
>: user to play in. That's a sandbox.
>
>in a sense.. I don't really like unix as a future OS, but that would
>be an example..
... And you think that it is sensible to head to Linux and UNIX
advocacy newsgroups, tell them that you don't like UNIX, give vague
suggestions about your "TAO of Operating Systems, and then expect
these people to implement your operating system for you.
Real sensible...
>: The chroot and limit resources idea doesn't lock one out of the
>: rest of the machine. There are plenty of globals left. Such as block
>: raw block devices! Tcp/ip. Etc.
>
>well I would rather you use these concepts as metaphors for how
>the new OS would work.
No metaphors. Give us clear isomorphisms.
> AFAIR
>: the argument was: 1) suppose we have a virus checker. 2) construct the
>: program that checks X and exits harmlessly if its a virus, but if
>: X is not a virus then it should do something nasty and virus-like to
>: its own system (impossible if run in a lower-level sandbox). Then
>: apply this program to itself. If the program is a virus,
>: it will never do anything to anything, and thus it can not be a virus.
>: If it is not a virus, then it will harm the system (sandboxed!) and
>: thus it is a virus.
>
>yes, a contradiction, its very similar to the halting proof by
>design. I'd say you've got it.
... But it misses the "Trojan Horse" approach, where the would-be
virus refuses to activate the "bad stuff" until it can establish a
communications link to a provably remote site (e.g. - "home") so as
to have reasonable evidence that it is running in a "real" system
rather than in a sandbox.
--
``What this means is that when people say, "The X11 folks should have
done this, done that, or included this or that", they really should be
saying "Hey, the X11 people were smart enough to allow me to add this,
that and the other myself."'' -- David B. Lewis <[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Julius <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: History
Date: Thu, 02 Sep 1999 03:31:15 GMT
The History of Linux from the beginning and how it's working compare with
other Operating Systems.
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: select() and FD_SETSIZE
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Sep 1999 03:33:21 GMT
On Wed, 01 Sep 1999 19:57:38 -0700, David Schwartz <[EMAIL PROTECTED]> wrote:
>you can never safely use any of the fd_set macros or select. It is the
>most horribly broken UNIX function I know of. I *never* use it when
>'poll' is available.
I think we can things up neatly with this table:
Bell Labs intellectuals Berkeley dope-smokers
-------------------------------------------------------------
Bourne shell C shell
poll select
write talk, talkd
memcpy and memmove bcopy
termios sgtty
Anything else?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: gdb Reference
Date: Thu, 02 Sep 1999 03:55:16 GMT
I am actually trying to find the procedure for setting up a remote
kernel debug session (is that well documented
somewhere?).
1) Is this the best way to debug a driver in Linux?
2) Where can I find the procedure to attach to the kernel with gdb?
(and can I do this locally or only remotely)?
Thanks
In article <7qkmc4$css$[EMAIL PROTECTED]>,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
> [<[EMAIL PROTECTED]>]
> > Does anyone know where "Using GDB: A Guide to the GNU Source- Level
> > Debugger, Richard M. Stallman and Roland H. Pesch, July 1991." is
> > posted on the WEB?
>
> No. Why? Most likely that book is somewhat outdated. Have you tried
> just using the texinfo manual that comes with?
>
> --
> Peter Samuelson
> <sampo.creighton.edu!psamuels>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: nick nelissen <[EMAIL PROTECTED]>
Subject: register_chrdev returns ok, but doesn't register anything!
Date: Thu, 02 Sep 1999 12:25:59 +0800
Hi,
I call register_chrdev(0,"name",fops) and it returns 254 which I presume
is the first available major number. However when I cat /proc/devices ,
I don't see anything. Of course unregister_chrdev fails as well.
I am using 2.2.10
I'm sure that it worked once before, but I forgot to unregister the
device.
I've rebooted many times since then.
There is no permanent storage of device numbers is there????
Any hints would be appreciated.
Nick Nelissen
------------------------------
From: [EMAIL PROTECTED] (Magnus Larsson)
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: Thu, 02 Sep 1999 05:28:38 GMT
On 1 Sep 1999 20:38:58 -0500, [EMAIL PROTECTED] (Peter
Samuelson) wrote:
>[BSD Bob <[EMAIL PROTECTED]>]
>> Any chance something like that would run on an old 7012/220 machine?
>
>Nope. They only support the latest 'n' greatest, i.e. PowerPC chip,
>CHRP motherboard, PCI bus, Open Firmware. I don't know what the 7012's
>are but I doubt they're any of the above, except maybe PowerPC.
Well...I have two model 355s and only have a corrupt install of
aix3.2.5 on them. Anyone have media for aix4.3 or something that I can
use (NOT commercial, just in edu purpose!) or can I run any other os
on this machines?
//Magnus
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: select() and FD_SETSIZE
Date: Thu, 02 Sep 1999 05:29:52 GMT
On Wed, 01 Sep 1999 19:57:38 -0700 David Schwartz ([EMAIL PROTECTED]) wrote:
| Worse, if you exceed the size of an fd_set, you will likely cause data
| corruption or crashes. The fd_set macros generally don't check range. So
| you can never safely use any of the fd_set macros or select. It is the
| most horribly broken UNIX function I know of. I *never* use it when
| 'poll' is available.
I've done a lot of programming with select(). The way you characterize
it just isn't so. If your use of the fd_set macros is done without
checking the proper bounds (or check them when you get fd numbers to
work with) then it's a programmer error, not a system call interface
design issue. You can just as easily cause such errors by passing an
invalid argument to poll() or by bad programming that fails to check
the bounds to your fdarray. Both select() and poll() cannot protect
against bad programming (nor should they try to).
I've used select() because it was more portable. Maybe today poll()
isn't so much of a problem. Still, I'm curious what the best way is
to check to determine if poll() exists? #ifdef POLLERR?
What I don't like about poll() is that it doesn't make expanding the
size of the fd array any easier. I either have to allocate a giant
fd array in anticipation of the maximum number of fds I might use, or
dynamically allocate and copy the contents around to change the size.
The poll() documentation does not indicate if the revent members have
to be cleared to 0 before calling poll(). And the SVR4 form of poll()
uses INFTIM for timeout for infinite time, whereas the Linux form uses
a negative number (according to documentation). This might still be
a portability issue.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 2 Sep 1999 05:43:28 GMT
ah, graffiti writes me. how apropos.
In comp.os.misc Graffiti <[EMAIL PROTECTED]> wrote:
:>I think this is a false dichotomy. I think when a designer runs into
:>this quandary it reflects a lack of imagination & engineering
:>ingenuity.
: Yup. Therefore, you should always design the OS to be so featureful,
: so robust, and so stable that you'll never, ever, have to upgrade or
: switch to another OS as long as you live, because you'll be familiar with
: all the issues that will ever come up and solve it before people realise
: it, right?
OSes will always be evolving. I'm proposing some of that
evolution specifically.
[sandboxes]
: So you're basically using a microkernel with each service in its own
: server, and each application running in a VM?
own server? the java concept would come pretty close. except
more direct code, not requiring the java bytecode.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 2 Sep 1999 05:44:48 GMT
In comp.os.misc Christopher Browne <[EMAIL PROTECTED]> wrote:
: It certainly seems to transcend *something.* I think what it is
: transcending is primarily someone's ability to do basic research...
hi chris. your peanut gallery comments are very amusing.
I do commend you.
what in particular do you have a problem with in the post?
or are you just smarting over the last flamewar in which
you got stung a tad by someone-or-other? hahaha
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 2 Sep 1999 06:03:15 GMT
In comp.os.misc Christopher B. Browne <[EMAIL PROTECTED]> wrote:
: ... And you think that it is sensible to head to Linux and UNIX
: advocacy newsgroups, tell them that you don't like UNIX, give vague
: suggestions about your "TAO of Operating Systems, and then expect
: these people to implement your operating system for you.
: Real sensible...
haha. very ridiculous I agree. but most people who use an operating
system tend not to be religious about it, and have things they
want to see improved about it. also I am preaching toward the crowd
that like Linux & open source and would like to transcend it.
: No metaphors. Give us clear isomorphisms.
ok chris. I'll see what I can come up with and maybe someday
I will pass the Browne test.
: ... But it misses the "Trojan Horse" approach, where the would-be
: virus refuses to activate the "bad stuff" until it can establish a
: communications link to a provably remote site (e.g. - "home") so as
: to have reasonable evidence that it is running in a "real" system
: rather than in a sandbox.
sorry, I'm not following. is the remote site running the same
virus proof OS or not? if so, it is virus proof. if not,
it is not virus proof. QED :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
