Linux-Development-Sys Digest #141, Volume #7 Thu, 2 Sep 99 05:14:19 EDT
Contents:
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: gdb Reference (Peter Samuelson)
Re: Disabling control-alt-delete from a program ("B. James Phillippe")
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: gdb Reference (David T. Blake)
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Oops-tracer wanted! (Andreas Peetz)
Re: Linux on RS/6000 (Peter Samuelson)
Re: gdb Reference (Peter Samuelson)
Re: gdb Reference (Peter Samuelson)
Re: TAO: the ultimate OS (Peter Samuelson)
----------------------------------------------------------------------------
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:55:49 GMT
In comp.os.misc Peter Samuelson <[EMAIL PROTECTED]> wrote:
: Whom are you accusing of lack of imagination or engineering ingenuity?
ahem. I regret you are misconstruing my post.
the point is that all software, viewed in retrospect, looks
like it lacks imagination & ingenuity. the more dated it
is, the more so this is true.
this is not to insinuate,
of course, the people who worked on it are nitwits. it is to suggest
that there is a moving goalpost in the realm of software
engineering.
: Not to imply that he's some sort of inerrant god, but in a Linux
: newsgroup Ted T'so brings a lot of credentials to the table. He has
: designed and built a lot of the stuff in Linux you use every day -- not
: by dreaming, not by "spreading the memes", but by actually working.
<looking at floor> aw, shucks, I respect that immensely.
: When he says it's been done, that it involves tradeoffs and that you
: can't just hand-wave those away, I think I'll take his word for it over
: yours. Have you actually tried implementing a sandbox architecture?
: How did *you* use your superior imagination and engineering ingenuity
: to overcome the problems he outlines?
ahem. I do think a far better sandbox architecture is possible when
one starts with that as the objective rather than other goals
such as performance optimization, which I propose to you is the
typical goal of most OS design. it seems to me mr. T'so himself
would agree that new architectures with new improvements are possible
& perhaps even inevitable.
: He didn't say "impossible", he said there are tradeoffs. Security
: versus ability to do anything useful. If you don't want your system to
: do anything useful, you can secure it real tight.
my simple assertion is that:
1. a virus proof system is possible
2. using a better concept of sandboxes
3. such a system would not suffer serious capability or
performance bottlenecks
4. counting the administrative time dedicated to
dealing with viruses, it would be better in the long run.
: As another poster said already, applying the concept of a sandbox to
: things like device drivers is simply adopting a microkernel
: architecture. In other words it's about as old and tired as the rest
: of your revolutionary ideas.
many objections to my ideas are in the form, "what you are proposing
is [x]. [x] has been tried". I am not very interested in debating
this. I will clarify [x] to those who ask intelligent questions.
: OK, but you've been arguing the inverse, i.e. the problems *will* go
: away when you *do* design the sandbox in an ingenious way that
: transcends all prior attempts lacking in imagination. A claim you most
: likely can't back up without actually showing us an actual new,
: ingenious sandbox design that shows promise of tackling some of these
: issues.
I am asserting it is possible. I am asserting it will be done,
regardless of my own contributions to the matter. I am not interested
in handing it down like moses from the mountain. I would like
to work with people who agree with my assertions above & want
to realize the vision.
to those who do, please sign up for the mailing list.
: Odd, that's what we've all been telling you this whole time. You seem
: to think that your OS *will* create itself if you just talk about it
: long enough.
it will, but no one will credit me of course. hahaha
We say talk is cheap, very cheap. Are you a PHB, by any
: chance?
talk is cheap, I agree. I even saw linux torvalds quoted saying
that recently. so it must be true. btw I have actually written
code.
Because sometimes you sound like one. You do need to pick up
: more of the lingo, though. Learn to use phrases like "thinking outside
: the box" and "rethinking paradigms".
hahaha. hilarious. yes we need a new paradigm. totally
agree with you on that one. could someone reboot my etch-a-sketch.
my new OS should be chiefly in the shade of mauve.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: gdb Reference
Date: 1 Sep 1999 21:11:16 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[<[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>
------------------------------
From: "B. James Phillippe" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Date: 2 Sep 1999 05:43:40 GMT
On Tue, 31 Aug 1999 [EMAIL PROTECTED] wrote:
> Can someone explain how to disable the console control-alt-del key
...
> I realise the program will have to be setuid root but thats not a
> problem.
...
You might want to investigate the loadkeys(1) option to remove the
CTRL-ALT-DEL binding to Boot. You can do this on the fly without fiddling
with init.
-bp
--
# bryan at terran dot org
# http://www.terran.org/~bryan
------------------------------
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:25:14 GMT
In comp.os.misc [EMAIL PROTECTED](edtoy) wrote:
: You have "give me ideas" and "do the work for me" interjected throuhout
: your dialog. You're just trolling for suckers. Get a life.
I am creating an environment (mailing list)
with a specific agenda for whatever use people desire
within the charter. I resent the frequent
canard here that one must have something exhaustive
prior to posting. how is it that someone contributing is
a "sucker"? a rather dark way of looking at the world. it
seems to me you are yourself saying, "do the work for me"
or "get lost".
again, for those who are interested & do not have
an immature, unproductive, "show me something I care
about" attitude, please sign up for the mailing list.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:44:31 GMT
Christopher Browne <[EMAIL PROTECTED]> wrote:
: 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...]
thats interesting, I cited EROS in the last thread I started
on the subject as something that was coming close to several
of the goals I'm espousing. I think they are making tangible
progress on some of the key design goals that should drive
a next-generation OS.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: gdb Reference
Date: 2 Sep 1999 05:52:03 GMT
Reply-To: [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?
The man page references the book and the info pages.
Info format kinda lacks friendly tools to view it with
compared to a hard back book.
--
Dave Blake
[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 06:18:17 GMT
In comp.os.misc Peter da Silva <[EMAIL PROTECTED]> wrote:
: Western society as a whole is "nonliterate hostile", and attempts to
: make it less so rarely work. If you want a computer for people who can't
: read or write, I recommend you look towards Nintendo and Sega.
if you want world domination, or perhaps merely an OS that isn't
a pain in the --- to install/use/maintain, I recommend you consider
a different attitude.
often what is idiot proof is also the easiest to use, for
users of all levels of sophistication.
I submit that a truly good OS & application environment would
not pit the experienced against the inexperienced, anyway.
its a false dichotomy only existent in existing systems
to date.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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: Andreas Peetz <[EMAIL PROTECTED]>
Subject: Oops-tracer wanted!
Date: Thu, 02 Sep 1999 09:02:21 +0200
Hi all,
I'm having strange problems here with a machine running
VMware, but I'm not sure whether VMware is causing the problem
or if it is a hardware problem or whatever.
The symptoms are
1. The NIC (an eepro100) stops working and the machine
becomes unresponsive. It even cannot be rebooted at the console.
In the system log there are repeating messages:
eth0: Transmit timed out: status 7048 0000 at 997542/997556 command 000ca000.
eth0: Trying to restart the transmitter..
2. processes reading an md(raid0)-device cause kernel oopses.
This problem occured with rdist and cp. Once it happened that a
cp of a large file (>1GB) just hung without any kernel messages and
could not be killed with "kill -9" until a reboot.
I attached such an Oops message. Can someone who is experienced in
Oops tracing please have a look at it?
Here is some information about the machine's hard- and software-configuration.
If any more information is needed to track down the problem please let me know!
- SuSE Linux 6.2
- Kernel 2.2.12-SuSE (SMP enabled)
- 2x Pentium III 450 MHz CPUs
- 1 Adaptec AIC-7895 Ultra Wide SCSI host adapter
- 1 Adaptec AHA-294X Ultra2 LVD/SE Wide SCSI host adapter
- 1 Intel EEPro100 NIC with Intel 82557 (rev 8) chip
(rev 8 is rather new. Are there any known problems?)
- 1 GB RAM (Large memory access is NOT enabled in the kernel
and I have "mem=960M" in lilo.conf)
- The raid0-device consists of 4x 4GB ST34573LW-disks that are
attached to both channels of the U2W-controller.
- VMware 1.03 is installed. The VMware modules (vmmon and vmnet)
were loaded when the Oops occured, but VMware was not running.
vmnet-bridge was there but eth0 was NOT in promiscous mode.
And here is the Oops log:
===================================================================================================================
Sep 1 17:36:43 frasvmhst01 kernel: Unable to handle kernel paging request at virtual
address 20676e69
Sep 1 17:36:43 frasvmhst01 kernel: current->tss.cr3 = 1281f000, %cr3 = 1281f000
Sep 1 17:36:43 frasvmhst01 kernel: *pde = 00000000
Sep 1 17:36:43 frasvmhst01 kernel: Oops: 0000
Sep 1 17:36:43 frasvmhst01 kernel: CPU: 1
Sep 1 17:36:43 frasvmhst01 kernel: EIP: 0010:[eepro100:eepro100_init+-121710/8753]
Sep 1 17:36:43 frasvmhst01 kernel: EFLAGS: 00010202
Sep 1 17:36:43 frasvmhst01 kernel: eax: 13057fd5 ebx: 20676e69 ecx: e8ad4510
edx: 00000006
Sep 1 17:36:43 frasvmhst01 kernel: esi: 4c15ff56 edi: fc812238 ebp: 00000002
esp: d89e7dfc
Sep 1 17:36:43 frasvmhst01 kernel: ds: 0018 es: 0018 ss: 0018
Sep 1 17:36:43 frasvmhst01 kernel: Process rdist (pid: 1062, process nr: 50,
stackpage=d89e7000)
Sep 1 17:36:43 frasvmhst01 kernel: Stack: 00000009 00000004 fc810000 00000004
fc80e000 00000008 00000400 c0167cf0
Sep 1 17:36:43 frasvmhst01 kernel: c020e900 e8ad450e e8ad4510 00000002
00000003 c0166986 00000000 e8ad450e
Sep 1 17:36:43 frasvmhst01 kernel: e8ad4510 00000002 00000004 cc15ff56
00015d0c 00000000 00000400 c0129af5
Sep 1 17:36:43 frasvmhst01 kernel: Call Trace: [eepro100:eepro100_init+-106572/8753]
[eepro100:eepro100_init+-114764/8753] [md_map+100/108] [ll_rw_block+234/524]
[brw_page+661/904] [generic_readpage+129/144] [try_to_read_ahead+269/292]
[do_generic_file_read+762/1540] [generic_file_read+99/124] [file_read_actor+0/80]
[sys_read+194/232] [system_call+52/56] [startup_32+43/164]
Sep 1 17:36:43 frasvmhst01 kernel: Code: 8b 03 03 43 08 39 c6 7c 1d 8b 5f 04 85 db 75
16 56 68 60 c6
===================================================================================================================
I welcome any hints and comments. Thank you,
Andreas
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: 2 Sep 1999 02:58:43 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Magnus Larsson <[EMAIL PROTECTED]>]
> Well...I have two model 355s
Yeah, *that*'s the kind of machines I was saying Linux will likely
never support....
> and only have a corrupt install of aix3.2.5 on them.
Is there any other kind? I have never had the pleasure of using AIX
3.2 but I have heard all about how wonderful it was. (:
> Anyone have media for aix4.3 or something that I can use (NOT
> commercial, just in edu purpose!)
Well I've got 4.3.2 here but I don't deal in warez. I could make
either the contents or the iso images available via ftp/http/4mm/8mm
but only if you manage to convince me that it wouldn't break any
license agreements with IBM. Which I doubt you will be able to do.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: gdb Reference
Date: 2 Sep 1999 02:47:08 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[<[EMAIL PROTECTED]>]
> I am actually trying to find the procedure for setting up a remote
> kernel debug session (is that well documented somewhere?).
Mmmm, dunno.
> 1) Is this the best way to debug a driver in Linux?
Depends on who you ask. printk() is your friend. Exposing something
via a temporary /proc interface is also a well-known method. And, of
course, developing the driver as a loadable module is much easier than
linked into the kernel, even if you don't plan to support the module
form after it's done....
> 2) Where can I find the procedure to attach to the kernel with
> gdb? (and can I do this locally or only remotely)?
You can run gdb on a local kernel subject to the same restrictions as a
remote one. Namely: you can't set breakpoints, you obviously can't
send signals, you can't write to kernel memory to change a variable.
In addition, the reason remote debugging exists at all is to try and
isolate the debugger from the running kernel. If you're trying to
debug memory mapping, and your local gdb happens to do a lot of memory
mapping, you can get unwanted feedback. And if something about memory
mapping tends to crash the machine or otherwise not work right, local
gdb won't be able to do its job. Remote gdb will, though, so long as
the serial or network interface is more or less intact. Which leads up
to: if you are just debugging a driver that isn't related to your
filesystem or your console, you probably want local gdb.
For remote gdb, I don't know the invocation beyond compiling the
appropriate kgdb stub into your kernel. For local gdb, you just need
to invoke gdb with the arguments "/usr/src/linux/vmlinux /proc/kcore"
where vmlinux is the original ELF binary (which gdb will grok), before
compression and other boot stuff is added on. /proc/kcore is a view of
kernel memory, and gdb will see it as a core file. (Just a core file
that has a habit of changing rapidly, so gdb can get confused on
occasion.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: gdb Reference
Date: 2 Sep 1999 02:50:08 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[David T. Blake <[EMAIL PROTECTED]>]
> The man page references the book and the info pages.
So *that*'s where the book is mentioned.
> Info format kinda lacks friendly tools to view it with compared to a
> hard back book.
You don't consider tex, dvips and lpr to be friendly tools? Note that
I originally said .texi, not .info.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
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 03:14:16 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> often what is idiot proof is also the easiest to use, for users of
> all levels of sophistication.
Not for me. I despise idiot-proof environments. Who said it? "Unix
does not prevent you from doing stupid things, because that would also
prevent you from doing clever things." I can get my work done much
faster due to those clever things that I *could* use to shoot myself in
the foot.
> I submit that a truly good OS & application environment would not pit
> the experienced against the inexperienced, anyway. its a false
> dichotomy only existent in existing systems to date.
I know you will accuse me of having no imagination, but the only way to
make a computer that thinks like a computer interact smoothly with an
"idiot" who does not think like a computer is to employ DWIM. That is,
the computer has to try and think less like a computer and more like a
human. Which makes the computer "more intuitive" for those who can't
or won't think like a computer.
Unfortunately, as you approach the less and less technical of users,
thinking like a human starts to entail introducing ambiguities,
redundancy, abstraction of a precise paradigm into a vaguer paradigm,
and other traits which inhibit efficient communication. Meaning that
I, the power user who is willing to learn to think like a computer,
will not be able to bypass these inefficiencies, much as I would like
to. I believe DWIM can never be one-size-fits-all.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** 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
******************************
