Linux-Development-Sys Digest #130, Volume #7 Tue, 31 Aug 99 15:14:15 EDT
Contents:
Re: iBCS2 emulator and kernel 2.2.x - help needed - urgent (Volker Dittmar)
Re: why not C++? (Kaz Kylheku)
Re: Jesus: the ultimate OS (Donal K. Fellows)
Re: write() (Wolfram Gloger)
Re: Jesus: the ultimate OS (James Andrews)
Re: TAO: the ultimate OS (Donal K. Fellows)
Re: Linux on RS/6000 (Dave Marquardt)
Re: Avoid Zombies (Kaz Kylheku)
Re: why not C++? (Don Waugaman)
Re: Question: Child Process I/O (Herng-Jeng Jou)
Re: Win95 is a bloody pain in th ass(after I installed linux)!! (Tristan Wibberley)
Re: ext2 and changing "reserved space" (is there a tunefs for ext2?) (Peter Pointner)
write() (Sven Heursch)
Re: MySQL, chroot and shared libs ("Sean O'Dell")
Re: write() (Kaz Kylheku)
Re: linux driver examples from rubini (ellis)
Re: select() and FD_SETSIZE (Miquel van Smoorenburg)
Re: Win95 is a bloody pain in th ass(after I installed linux)!! (jwk)
Re: Jesus: the ultimate OS (Graffiti)
Disabling control-alt-delete from a program ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Volker Dittmar <[EMAIL PROTECTED]>
Subject: Re: iBCS2 emulator and kernel 2.2.x - help needed - urgent
Date: Tue, 31 Aug 1999 13:50:12 +0200
Markus Lang wrote:
> Hi,
> I've a problem with the iBCS emulator and SMP support.
> With kernel 2.2.10, 2.2.11 and 2.2.12 and a non-SMP-
> kernel the emulator just works fine.
>
> But our production server is an SMP machine (Intel, Pentium
> II,
> Asus board). With a SMP-enabled kernel I can't 'insmod' the
> iBCS emulator. It fails with:
>
> /lib/modules/2.2.12/misc/iBCS: unresolved symbol kernel_flag
The problem has been solved!
You have unset CONFIG_MODVERSION for the kernel AND
you have to set USE_VERSIONS=no in the iBCS-CONFIG-file.
This was different for older versions.
Ciao,
Volker
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Aug 1999 21:30:02 GMT
On Mon, 30 Aug 1999 18:33:26 GMT, NF Stevens <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Don Waugaman) wrote:
>
>[snip]
>
>>References also cannot be induced to point to NULL in a strictly-conforming
>>program, which can eliminate a lot of checking of input conditions (or more
>>practically, since most C routines don't check their input parameters
>>anyway, can make the use of such routines much more reliable).
>
>#include <cstdio>
>
>char *GetAddress (char &c)
>{
> return &c;
>}
>
>int main (void)
>{
> char *p = NULL;
> printf ("%p\n", GetAddress (*p));
> return 0;
>}
>
>Which part of the this program is not strictly
>conforming?
The part where you dereference the null pointer. There is a difference between
a strictly conforming program and one that compiles without diagnostics. :)
However, that difference is often only theoretical; your real point seems to be
that the language doesn't have an inherent mechanism for statically checking
this case. One has to rely on careful verification and the application of
tools.
It would appear that in practice, a const-qualified pointer is about
as safe as a reference.
------------------------------
From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: 31 Aug 1999 12:47:29 GMT
In article <7q1pmr$[EMAIL PROTECTED]>,
Eric Goold <[EMAIL PROTECTED]> wrote:
> Tim Kelley wrote in message <[EMAIL PROTECTED]>...
>> Where is it in the bible that jesus had sex? Why didn't he?
>
> I THINK it may have been because he had something better to do?
But they hadn't invented chocolate or computers...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
------------------------------
From: Wolfram Gloger <[EMAIL PROTECTED]>
Subject: Re: write()
Date: 31 Aug 1999 16:15:15 +0200
Sven Heursch <[EMAIL PROTECTED]> writes:
> in linux systemcalls are not preemptiv.
> soI call write() in Linux to put 1 GB in a file. After entering the
> kernel modus the systemcall sys_write() begins to write the 1 GB into
> the file. Is it true that the process cannot be preempted by the
> scheduler for the whole time he is writing?
Yes, this is true -- if you consider preemption as only happening due
to the timer interrupt. However it doesn't mean that no other process
is scheduled during the system call! What happens is that the device
driver performing write() will at some point have to wait for the I/O
hardware, and then it will (directly or indirectly) invoke schedule()
voluntarily so other tasks can run.
Regards,
Wolfram.
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: Tue, 31 Aug 1999 12:33:28 +0000
Reply-To: [EMAIL PROTECTED]
> Are you *trying* to advocate having everyone manually toggle bits to
> create machine code in hardware? Because that's what it sounds like.
Obviously this concept is intangible and requires no further discussion.
> All languages have to have translators. It's just a question of when
> the translation occurs: Just once, when the programmer is making it,
> in which case it's a 'compiler', or every time it is run, in which
> case it's an interpeter. (Or once per user session, in which case
> it's a JIT compiler.)
You are generallising from a lax modern knowledge of computing, but
unfortunately, you are quite wrong. For a start, the difference between
an assembler and a compiler is this; An assembler takes mneumonic code
and converts it into machine readable code, but the mneumonics are
directly representative of the machine code produced. Compilers on the
other hand generate their own machine code, not directly related to the
source, to implement the algorithms written in the theoretical language
for which the compiler was written.
Your description of interpreter was closer. An interpreter is basically
a stream translater of a given code.
As for JIT compilation, as far as I remember JIT is the name of one
particular compiler, the Just-in-time compiler for java. Which
incidentally is different to all of the other cases you have mentioned
and a little to specific to use as an example in the context you have.
The concept you refer to, I would imagine, would be a runtime compiler,
software to generate the native code from whatever format at runtime,
when the software is needed. These are indeed possibly the most
interesting of the family, and you should expect to see many more in the
near future.
A compiler may change the structure of your software, it may even
occasionally change what it does, but most importantly, it abstracts the
method of software engineering up to a higher ground. It makes it
easier, or in some cases possible, to instruct a machine to do things
that would take far, far too long to write by hand.
Obviously there are two sides to the usage of compilers, hence the
argument to which I've added this comment, but at the end of the day
unless the theorised "java processor" mentioned in Nix's post becomes a
reality, the benefits of compilation far outway the deficits.
Compilers can be used as one off code generators, as in the case of c
and c++. This means the additional processor performance is only
required once, after which you have native code, which is as efficient
as you could want (almost always). Even with runtime compilation (your
JIT) well programmed systems can compile the source to native code while
other components are being collected (loaded, downloaded, etc). This
means no performance deficit, a little more effort needed during
loading, and the possibility of platform independence. Can you possibly
say that the downsides here outweigh that?
James
PS. I apologise for cross posting, but the cross posting occured in the
post I am replying to, and I dont know which of the groups are read by
the author of said post. Sorry.
------------------------------
From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 31 Aug 1999 14:54:57 GMT
In article <7qep58$[EMAIL PROTECTED]>,
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
[ Virus checking a la Halting problem ]
> what this proof fails to consider is the concept of a sandbox. an
> environment can be constructed such that a program running in it is
> constrained to a sandbox. concepts such as "corrupt operating
> system" and "calling a function" are possibly barred from definition
> within this sandbox.. i.e. they are not possible.
Hmm. You are sacrificing the abiliity of the system to describe
itself for greater theoretical tractability (this is all based on the
G�del Incompleteness stuff - any system capabile of describing itself
is paradoxical[*].) It is the heart of all sandbox security schemes.
> moreover the proof supposes that a program that doesn't actually do
> anything harmful in practice is not a virus. but imho, any program
> that even has the code within it "corrupt operating system" (which
> could be detected by a virus checker) is potentially a virus.
> barring it from execution leads to no harm, even if it wouldn't
> actually corrupt the OS in practice. what is possibly gained by
> allowing to run a program that can potentially corrupt an operating
> system, but doesn't?
If you can exhibit a proof that a given program does not corrupt its
host system, then you do not need to run the program in a sandbox. In
many ways, at that point it is the proof that is the sandbox! (Mind
you, I've not said anything about the nature of the proof. That is a
*deep* topic, not well-suited to USENET. Or the Web. Proof for pure
functional programs is hard enough as it is...)
I'll tell you what you could do which would make peoples' lives easier
in dealing with your concepts. Put a load of essential use cases up
on your website. While these are not as good as a detailed spec, they
do help a lot with the understanding of how the various features of
the overall system interact. A lot of software engineers (ought to)
do this (and UML provides some support) and it certainly seems to be
good practise at the "defining what exactly is meant by everything"
stage.
(When this thread's good, its very very good. And when it is bad, it
is horrid! :^)
Donal.
[* I can't think of any paradoxes that are not self-referential. Anyone? ]
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
------------------------------
From: Dave Marquardt <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: 31 Aug 1999 08:48:24 -0500
[EMAIL PROTECTED] (Magnus Larsson) writes:
> I wanna start an organized Linux development on the RS/6000. Anyone
> interested?
There's a company called Yellow Dog that's selling Linux for RS/6000.
-Dave
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Avoid Zombies
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 15:34:42 GMT
On Tue, 31 Aug 1999 08:21:37 +0200, Sven Heursch
<[EMAIL PROTECTED]> wrote:
>
>I am using RedHat 6.0 with glibc 2.1.1 and the gcc 2.7.2 on a 486er machine.
I sent in one patch for the 2.1.1, but it's not related to zombies. There was a
serious crash bug in the case when there are no more processes available---that
is, clone() fails. In that case, the code deallocates the resources that it
acquired in preparation for the thread, but fumbles the order, resulting in a
segmentation fault in the thread manager. With the thread manager gone,
pthread requests that go through it deadlock.
No clue on the zombie issue. I'd look at it if you'd be willing to make a small
program that demonstrates the problem.
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 31 Aug 1999 09:26:08 -0700
In article <[EMAIL PROTECTED]>,
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>Maybe with respect to null pointers. But what about dangling references?
>It's easy to create references to objects that no longer exist, because
>their enclosing statement block has terminated or have been deleted.
>This is yet another way in which references are as unsafe as pointers.
There's one way to do this: returning a local variable by reference from
a function. On the other hand, it is possible to point a pointer to
a variable that goes out of scope within a function while the pointer
is still valid.
The solution is simple: never return a local variable by reference from
a function.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
If tin whistles are made of tin, what are foghorns made of?
------------------------------
From: Herng-Jeng Jou <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Question: Child Process I/O
Date: Tue, 31 Aug 1999 08:49:10 -0500
Thanks a lot for your reply. I'll take a closer look of the code you posted.
At a quick glance of it, it seems to use full-duplex pipe to communicate with the
child program. It can be done, on Linux, using stream based pipe (socketpair).
Yes, I am trying to drive a command-line program from within my program.
The parent process sends input to the child command-line program based on
the output of the child. So, I need to know when the child is idle (waiting for
further input) and to get all the output before further input. The problem is I
do not know how to collect all output not pass the buffer .... if I use fgets()
in a loop, it eventually stays there waiting for more output from child while
the child is waiting for input ... I had to quit it by Ctrl-C. I think I need to
learn more about the terminal device I/O programming and also take a look
of the code you sent.
Jou
Vassilis Virvilis wrote:
> Peter Samuelson wrote:
> >
> > [Herng-Jeng Jou <[EMAIL PROTECTED]>]
> > > In the parent process, how do I determine when the child process has
> > > done its number crunching and is waiting for further input? Should I
> > > use /proc?
> >
> > Don't bother trying. Just send it input as fast as you can, and let
> > the kernel block you when it's tired of buffering you.
> >
> > > How do I determine whether there is still something in the output
> > > buffer?
> >
> > Not easy. I still don't understand why you need to do this.
> >
> > > In a sense, I need an I/O facility similar to a debugger so the
> > > parent process can talk to the child program.
> >
> > The only way I can think of to do this without source code would be to
> > insert hacked stdio functions into the binary via LD_PRELOAD. This is
> > of course assuming that your binary's stdio is dynamically linked.
> >
>
> I think he is trying to drive a command line utility (a program with a command
> line, e.g. like gnuplot) from a master program. The same functionality is
> achieved by the pair of octave/gnuplot though gnuplot allows non interactive
> execution (gnuplot file.gnp) and since I haven't seen the code I don't know how
> they are doing the trick.
>
> Here is a sample of code that does the trick and works under UNIX (Linux,
> Solaris, SunOs) and win32 which is of course a debatable feature. If you don't
> want the WIN32 compatibility the code becomes much cleaner (suprise, suprise).
>
> In case somebody wonders the code snippet is taken from billnet, the Fast & Free
> Neural Network Simulator which is a free project of mine.
>
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Win95 is a bloody pain in th ass(after I installed linux)!!
Date: Wed, 01 Sep 1999 07:37:12 +0100
Reply-To: [EMAIL PROTECTED]
"Santosh H." wrote:
> Well my problem is this.I have a comp at home which runs win95(+
> Linux) .To install linux I deleted all extended DOS partitions using
> fdisk(I'm using vfat mind) and created the new ext2 partition using cfdisk
> when I installed linux.Then when asked I installed LILO (to the
> superblock of my linux partition) and then to test
> what'd become of my win95 at the boot prompt I told it to boot my first
> win95 partiton.Fine Win95 boots but when I try to open My Computer it just
> hangs the system.Ditto with all the software I have when I try to chande
> drives from the open dialog.
Uhh, this may be a stupid question, but was there anything on those
extended dos partitions? Just in case - you do have backups right?
--
Tristan Wibberley
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: ext2 and changing "reserved space" (is there a tunefs for ext2?)
Date: Mon, 30 Aug 1999 18:39:34 GMT
tune2fs
------------------------------
Date: Tue, 31 Aug 1999 14:18:44 +0200
From: Sven Heursch <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: write()
Hello,
in linux systemcalls are not preemptiv.
soI call write() in Linux to put 1 GB in a file. After entering the
kernel modus the systemcall sys_write() begins to write the 1 GB into
the file. Is it true that the process cannot be preempted by the
scheduler for the whole time he is writing?
TIA
S. Heursch
------------------------------
From: "Sean O'Dell" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.networking,comp.os.linux.security
Subject: Re: MySQL, chroot and shared libs
Date: Tue, 31 Aug 1999 07:24:20 -0700
I KNEW IT!!! Haha...I knew someone would not be able to resist making a
comment on security!!!
But you are certainly right about complex. Chrooted environments, I've
learned, are just not fun places. However, I have no choice, it is my best
security option for this particular program. Not to mention that it hides
the rest of my users from each other, which makes it fun for them. But if I
don't solve this issue of domain name resolution, it will not be a fun place
for them either anymore.
-Sean
Nigel Metheringham <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Mon, 30 Aug 1999 20:16:20 -0700, Sean O'Dell <[EMAIL PROTECTED]> wrote:
> >Well, your suggestion actually lead me to the actual problem I think. I
> >tried using the domain name for the mysql server and got pretty much the
> >same results. However, when I tried the plain old IP address, it worked
> >just fine. So, it's got something to do with my DNS lookup activities
> >somewhere. Gonna track that down...thanks for the info!
>
> You appear to be making your chroot environment more and more complex,
> which makes it harder and harder to fully secure.
>
> Why not:-
>
> 1. Static link your program. That definitely rids you of
> needing a pile of internal library images. It means
> you have to recompile for even minor updates in the
> supporting libraries, but thats a similar degree of
> work to upgrading the libraries within your chroot
> jail.
>
> 2. Don't attempt to use a named pipe connection - too
> much like hard work and a potential for desecuring
> your server
>
> 3. Make the program do its DB connections to 127.0.0.1
> [ie loopback] - no serious performance hits since it
> doesn't hit the real network, and that IP is always
> your local machine. No DNS libraries needed at all
> [although they are probably linked in by step (1).]
> nor additional DNS config - ie /etc/resolv.conf &
> /etc/nsswitch.conf
>
> Nigel.
>
> --
> [ Nigel Metheringham -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [EMAIL PROTECTED] ]
> [ Playing with technology razor blades - close to the bleeding edge ]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: write()
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 17:30:40 GMT
On Tue, 31 Aug 1999 14:18:44 +0200, Sven Heursch
<[EMAIL PROTECTED]> wrote:
>Hello,
>
>in linux systemcalls are not preemptiv.
>soI call write() in Linux to put 1 GB in a file. After entering the
>kernel modus the systemcall sys_write() begins to write the 1 GB into
>the file. Is it true that the process cannot be preempted by the
>scheduler for the whole time he is writing?
No, you are confusing Linux with MacOS. ;)
Although system calls are not preemptive, they voluntarily give up the
processor at key times, such as when it is necessary to wait for buffers, or
the completion of I/O. This is done by an explicit call to the scheduler. Long
read or write operations are interrupted in that manner. If you are curious,
read the code.
------------------------------
From: [EMAIL PROTECTED] (ellis)
Subject: Re: linux driver examples from rubini
Date: 31 Aug 1999 18:06:48 GMT
In article <7qfb86$m62$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Has someone been able to make rubini's examples
>work on 2.2.+
Take a look at http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.2.html
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: [EMAIL PROTECTED] (Miquel van Smoorenburg)
Subject: Re: select() and FD_SETSIZE
Date: 31 Aug 1999 19:23:06 +0200
In article <[EMAIL PROTECTED]>,
Christian Schlange <[EMAIL PROTECTED]> wrote:
>Hello,
>
>I've one question concerning the select()-function on linux-systems :
>
>Is the number of file-descriptors you can use with the select-function
>limited.
No, not really. Well, to the max # of filedescriptors you can
have open, which is hardcoded to 1024 per process.. and that
corresponds to FD_SETSIZE.
2.2.12 has fixed this restriction and you can use ulimit(1) to raise
the max # of filedescriptors a process can have opened to insane
values.
>And if so, can one adjust the maximum value via the
>FD_SETSIZE-define ??
Probably yes. However you have to be careful that you don't use
filedescriptors > 1024 with any librarycalls that call select,
such as the RFC stuff. Because the library functions have been
compiled with the smaller FD_SETSIZE.
Mike.
--
... somehow I have a feeling the hurting hasn't even begun yet
-- Bill, "The Terrible Thunderlizards"
------------------------------
From: [EMAIL PROTECTED] (jwk)
Subject: Re: Win95 is a bloody pain in th ass(after I installed linux)!!
Date: 31 Aug 1999 18:04:46 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 31 Aug 1999 14:44:32 +0530, Santosh H.
<[EMAIL PROTECTED]> wrote:
>Hi all,
> Sorry for the bad language but Win95 is one bloody stinking bit of
>software.
>
> Well my problem is this.I have a comp at home which runs win95(+
>Linux) .To install linux I deleted all extended DOS partitions using
>fdisk(I'm using vfat mind) and created the new ext2 partition using cfdisk
>when I installed linux.Then when asked I installed LILO (to the
>superblock of my linux partition) and then to test
>what'd become of my win95 at the boot prompt I told it to boot my first
>win95 partiton.Fine Win95 boots but when I try to open My Computer it just
>hangs the system.Ditto with all the software I have when I try to chande
>drives from the open dialog.
I hope you didn't have any software on those extended partitions....
>
> Could someone please tell me what I must do to fix the problem cos my
>Mums's yelling at me :-( cos she can't open some spreadsheet she's made
>with MS Excel(For those wisecracks advising me to move to StarOffice ,my
>mom hates Linux just as much as I hat win95(both pre & post linux days)).
... like spreadsheets for example :-(
You *know* the magic word that is written in any manual: backup first,
test the backup, then continue.
I guess you need'll need to be tough to withstand your mother :-)
Good luck with it,
Jurriaan
--
According to the obituary notices, a mean and unimportant person never dies.
------------------------------
From: Graffiti <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: 31 Aug 1999 11:42:04 -0700
In article <[EMAIL PROTECTED]>,
Nix <$}xinix{[email protected]> wrote:
[snip]
>> The idea that code be
>> transportable and then install a unique processor to make it run well
>> seems just a little bit strange to me.
>
>Why? The UCSD P-system did it back in the early 80s. All the Infocom
>games did it (with the `Z-machine') and it is because of that that I am
>able to copy Zork off my C64 floppies, throw it onto my Linux box and
>run it (via an interpreter of course).
Um, wouldn't it be easier to grab the data files and run a Linux-native
Z-code interpreter? There are free ones out there, and the data files
are architecture independant. I play all the Infocom games I bought
(Masterpieces of Infocom CD) via that interpreter. pinfocom, I think
(I invoke it via make, so I don't remember the name anymore.)
>Do *that* with a 20 year old non-interpreted program. Unless it's
>written in damned portable C (which means there is not much it can do as
>so much changes over time, even in the Unix world) you are probably
>stuffed. And if it's a binary you are guaranteed stuffed unless you can
>get a system that emulates the entire system the binary ran on in, you
>guessed it, a virtual machine.
You can run XENIX binaries via iBCS, so you're not completely out of luck.
And if it's written in C, portable or not, you can still hack it to work
on Linux. If you don't have the source, it won't work via iBCS, and you
absolutely, positively, MUST run this program (and your last working
hardware dies), then you have problems.
>Although if Inferno ever gets mainstream I think we'll see what a
>network computer should *really* be :)
Hellish? :-)
>'Twas originally called `Freakx' when it first hit the net. (Although
Freax, actually.
-- DN
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Disabling control-alt-delete from a program
Date: Tue, 31 Aug 1999 18:41:36 GMT
Can someone explain how to disable the console control-alt-del key sequence
so that if an important program is running some bozo can't reboot the
machine short of doing a hardware reset. I realise the program will have
to be setuid root but thats not a problem. I know its possible since the
XF86 server accomplishes it somehow (though I've never understood why it
bothered)
NJR
------------------------------
** 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
******************************
