Linux-Development-Sys Digest #134, Volume #7 Wed, 1 Sep 99 07:13:56 EDT
Contents:
Re: why not C++? (Stephan Houben)
Re: The optimization debate (was: why not C++?) (Peter Samuelson)
Re: LispOS? (Peter Samuelson)
Re: Jesus: the ultimate OS (Peter Samuelson)
Re: Programming under XWindows (Nick Roux)
Fancy gcc compile error (Klaus Schneider)
Re: TAO: the ultimate OS (Peter Samuelson)
Re: Disabling control-alt-delete from a program (Peter Samuelson)
Re: Kernel compile problem with (P)GCC 2.95 (Andreas Spengler)
select() and FD_SETSIZE (Christian Schlange)
Re: TAO: the ultimate OS (Peter T. Breuer)
Re: Jesus: the ultimate OS (Donal K. Fellows)
Re: Jesus: the ultimate OS (James Andrews)
Re: Get ETH hardware address from user program (Peter Samuelson)
Re: Getting the Ethernet ID from directly from the network card. (Stefan Waizmann)
Re: Get ETH hardware address from user program (Peter Samuelson)
Re: select() and FD_SETSIZE (H. Peter Anvin)
Re: Disabling control-alt-delete from a program (Emile van bergen)
----------------------------------------------------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 01 Sep 1999 09:00:02 +0200
[EMAIL PROTECTED] (Don Waugaman) writes:
> In article <[EMAIL PROTECTED]>,
> Timo Tossavainen <[EMAIL PROTECTED]> wrote:
> >Don Waugaman wrote:
> >
> >C++ers usually miss the point of that Lispers and Smalltalkers have known for
> >some time. I think there's a "market" for a GPL'd C++ interpreter that checks
> >the code for array bounds, invalid casts, pointer dereferencing, memory
> >deallocation, etc. all the stuff that C++ doesn't check at run-time.
[snip]
> On the other hand, writing a C++ interpreter is an experience I wouldn't
> wish on my worst enemy. Just parsing the language for compilation is bad
> enough, and working through the various issues with different compilation
> units could turn into a nightmare.
I have good news for both of you: there is already such an interpreter,
called Cint. It is "almost free" in the free-speech sense.
You have to register at Hewlett-Packard for commercial use, but
registration is free.
(It was on my Suse 6.0 CD.)
Greeting`s,
Stephan
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: The optimization debate (was: why not C++?)
Date: 1 Sep 1999 02:36:06 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Chris Browne <[EMAIL PROTECTED]>]
> > Once optimized once, it's harder to optimize the code again.
[Stephen E. Halpin <[EMAIL PROTECTED]>]
> If this werent true, all processes would converge to O(1), and all
> data sets would compress to a single bit.
Heh, this reminds me of an article in JIR[1] back in 1993 about a great
new data compression algorithm. Basically, you take the data, view it
as binary, throw away the 0's as containing no information, count the
1's you have left, express *that* as binary and repeat -- until you're
down to a single 1. Reportedly they were still working on the
decompression algorithm.
[1] The Journal of Irreproducible Results, a spoof of a scientific
research journal, published at MIT. I have no idea if they're
still around.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: LispOS?
Date: 1 Sep 1999 02:28:28 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Chris Mahmood <[EMAIL PROTECTED]>]
> > Well, how much longer will it be before we can just boot emacs?
[Nix <$}xinix{[email protected]>]
> `ln /usr/bin/emacs /sbin/init' is your friend.
Hey, there you go. Who was it that said "Emacs is my OS, Linux is my
device drivers"? So ... can Emacs run as a proper `init'? As I see
it, init must do two things (not counting silly things like starting
getty): (a) wait for adopted children, and (b) respond to ctrl-alt-del.
For (a), who knows? It wouldn't be hard to add it though. For (b),
hmmmm, let's see...
(defvar shutdown-hook nil "Hook run before machine shutdown.")
(global-set-key "\C-\M-\?"
'(lambda nil
(run-hooks 'shutdown-hook)
(run-init-scripts "/etc/rc6.d"))) ; Debian location
--
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: Jesus: the ultimate OS
Date: 1 Sep 1999 02:53:12 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
Nix <$}xinix{[email protected]>]
> > 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).
[Graffiti <[EMAIL PROTECTED]>]
> Um, wouldn't it be easier to grab the data files and run a
> Linux-native Z-code interpreter?
Umm, that's what Nix was saying. His point being that a Z-code
interpreter is essentially a sort of virtual machine.
> > 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.
The difference here being that iBCS is for the same hardware
architecture. It is a runtime environment, which is a lot less
ambitious than an emulator aka virtual machine. If your binary
software is for different hardware you *will* need some sort of VM.
> And if it's written in C, portable or not, you can still hack it to
> work on Linux.
...But ask the people working on Winelib how non-trivial this can be.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Nick Roux)
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.free-widgets.development
Subject: Re: Programming under XWindows
Date: Wed, 01 Sep 1999 08:04:53 GMT
Reply-To: [EMAIL PROTECTED]
If you are coming from Delphi, you might want to have a look at
KDevelop. Not anywhere near the same, but familiar enough to make you
feel at home right away.
Nick
On Tue, 31 Aug 1999 23:36:45 +0200, "Darius Blaszijk"
<[EMAIL PROTECTED]> wrote:
>Hello there,
>
>After making some small programs using GCC, I decided to start programming
>under XWindows. But somehow I cannot find the information I need.
>
>First of all, what kind of software do I need to be fully equiped. I have
>the SuSe 6.1 distribution. (I'm used to program under WIN98 using DELPHI and
>I want to have the same sort of funcionality under LINUX)
>
>Second, where can I download the software I need extra?
>
>Third, can anyone explain me briefly how widgets work? Is it the same as
>components under DELPHI?
>
>Thanks in advance, Darius Blaszijk
>
=================================
mailto:[EMAIL PROTECTED]
http://www.bigfoot.com/~nick.roux
./spam>/dev/null
=================================
------------------------------
From: [EMAIL PROTECTED] (Klaus Schneider)
Subject: Fancy gcc compile error
Date: 1 Sep 1999 07:27:37 GMT
Hi Linux gurus,
when compiling gcc-2.95, I got some strange errors. Look at the
following lines from gcc/intl/localealias.c. Here, the compiler
(egcs-1.1.2) complained: "void value is not ignored as it should be"
map[nmap].alias = memcpy (&string_space[string_space_act],
alias,alias_len);
map[nmap].value = memcpy (&string_space[string_space_act],
value, value_len);
I can't see any errors in the code, but anyway I changed it to the code
below which should do the same:
map[nmap].alias = &string_space[string_space_act];
memcpy(map[nmap].alias,alias,alias_len);
string_space_act += alias_len;
map[nmap].value = &string_space[string_space_act];
memcpy(map[nmap].value,value, value_len);
string_space_act += value_len;
And then, everything went allright.
Now, trying to check out why this strange error occured, I built a
test application:
char zw[11],*string="Teststring",*zeig;
zeig = memcpy(zw,source,11);
printf(zeig);
And however, everything compiled allright.
What's the matter here? Is this a compiler bug?
Thanks for your help,
Klaus
------------------------------
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: 1 Sep 1999 03:27:13 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> it would be possible to limit programs to open files within their own
> "sandbox".. they have a section of the disk, say 2 meg or whatever is
> chosen by the user, within which they can create any files or data
> that is preferred, delete anything, etc. files outside the sandbox
> are "read only" or possibly not available for read at all.
I.e. Unix with quotas and filesystem permissions cleverly configured.
> this is such an utterly basic/trivial concept yet by today's OS
> measures, revolutionary. notice how even Unix does not have a sandbox
> in many ways, such as with forking. sometimes programs are not
> limited in how many times they can fork or how much system memory or
> disk space they decide to suck up.
Are you aware of the standard Unix "ulimit" mechanism? It's an awful
lot like what you are describing and is not new.
If your version of the sandbox concept doesn't do anything more radical
than limiting what files can be read or written and the amount of
system resources a user or process can consume, I don't see what you're
bringing to the table that Unix doesn't already have. Resource limits
in Linux are somewhat crude -- limits that are per-process don't all
have per-user equivalents -- but the *concepts* are not revolutionary
in the least.
Most of the argument of this thread centers around your goal of making
viruses impossible by design. In a sense, all modern operating systems
do this already through use of things like file permissions. Worms and
trojans still happen but if they can get around standard user access
controls (i.e. users cannot be allowed to screw over each other or the
system) it is the result of either a specific bug or someone who should
have known better than to run untrusted code as root.
So, you are going to somehow prevent these things from happening. Do
you propose to just architect an airtight, bugless system? Or are you
going to protect the system from its administrators? Neither route
sounds very practical. If I may say so, very little of what you have
written about concerning your vaporware sounds very practical.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Date: 1 Sep 1999 03:47:58 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[<[EMAIL PROTECTED]>]
> Yeah , I know about inittab, but I'm specifically looking to be
> enable and disable it from certain programs. Like I said , XF86 can
> do it so their must be some system call buried in libc or similar to
> be able to do it.
I think XFree opens and uses the raw virtual console device rather than
/dev/tty7 or whatever, so that it has lower-level control of the
keyboard i.e. can set LEDs and can handle every press/release event
rather than just getting typed characters through the console vt102
interface. This is also how it keeps Alt-F1 and friends from switching
the VC out from under it (which would be bad, because a program running
on another VC wouldn't be expecting the graphics-mode state the VGA
card was in).
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Andreas Spengler)
Subject: Re: Kernel compile problem with (P)GCC 2.95
Date: 1 Sep 1999 10:45:21 +0200
Hi Dave,
Dave Hearn ([EMAIL PROTECTED]) wrote:
: excuse my dumb question - did you run lilo before rebooting?
Yes, the make bzlilo calls lilo in the end...
: Andreas Spengler wrote:
: >
: > Hi folks,
: >
: > I recently upgraded my compiler to GCC 2.95 and now whenever
: > I try to compile a kernel (tried it with 2.3.11-15 and 2.2.9) and do
: > a make bzlilo, towards the end I get the warnings
: >
: > Warning; using %eax instead of %ax due to ..... ???
: >
: > When I reboot the system the kernel hangs at
: >
: > Uncompressing Linux. OK. Booting kernel......
: >
: > From then on I �ve to press the reset button to reanimate my system.
: >
: > Does anyone know why this happens ???
: >
: > Greets,
: >
: > Andreas Spengler
Thanks anyway,
Andreas
------------------------------
From: Christian Schlange <[EMAIL PROTECTED]>
Subject: select() and FD_SETSIZE
Date: Tue, 31 Aug 1999 17:08:03 +0200
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. And if so, can one adjust the maximum value via the
FD_SETSIZE-define ??
Thanks a lot,
Christian
------------------------------
From: [EMAIL PROTECTED] (Peter T. Breuer)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 09:10:36 GMT
Reply-To: [EMAIL PROTECTED]
Peter Samuelson ([EMAIL PROTECTED]) wrote:
: Are you aware of the standard Unix "ulimit" mechanism? It's an awful
: lot like what you are describing and is not new.
: If your version of the sandbox concept doesn't do anything more radical
: than limiting what files can be read or written and the amount of
C'mon folks, don't be dense. He means a virtual unix provided to the
user to play in. That's a sandbox.
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.
: Most of the argument of this thread centers around your goal of making
: viruses impossible by design. In a sense, all modern operating systems
>From what I saw, he was seeking to apply the "hierarchy of universes"
resolution of the typing paradoxes in strong type systems (or
equivalently, the hierarchy getout from russels paradox ..) to the
virus checking proof. I.e. the proof only says that a sufficiently
powerful system can't tell itself from a virus, because it can choose
to act like a virus and make its decision invisible. That leaves
it possible that a system of level n can detect viruses in a system
of level n-1, because they can't get out of their level n-1 sandmox and
pollute the system at level n.
I'm not sure I followed the quoted impossibility proof for virus
checking, however! Something appeared to have been left out. 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.
It seems to me that the proof works irrespective of sandboxing. What
would stop the proof would be that every program is run in its own
sandbox.
Peter
------------------------------
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: 1 Sep 1999 09:14:02 GMT
In article <7qh8f7$t0i$[EMAIL PROTECTED]>,
Graffiti <[EMAIL PROTECTED]> wrote:
> James Andrews <[EMAIL PROTECTED]> wrote:
>> 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?
>
> Yup. It's more stuff to debug, it add extra processing that will bog
> the system down if you're doing other things that content for the same
> resouce (CPU for JIT vs CPU for streaming audio. You use a JIT-compiled
> app to do streaming audio, it gets worse).
OTOH, you try doing stuff like loading and running untrusted code
across the network (not just for toy uses like applets, but for
serious stuff like CORBA stub servers) and doing it in a *secure*
fashion. That is simply not possible (without an amazing amount of
hardware/OS help at least) with C/C++. Quite apart from the fact that
you also have to have stubs for all the different platforms you wish
to deploy on...
Only the likes of M$ are arrogant and stupid enough to suggest loading
C/C++ binaries across a network as a serious solution!
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: 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: Wed, 01 Sep 1999 10:12:21 +0000
Reply-To: [EMAIL PROTECTED]
> Take a look at MASM, for example. You have the MOV instruction. Now,
> based on the type of data you pass it as an argument, it can generate
> different machine language instructions. MOV AX,BX and MOV AH,BH are
> two completely different things in machine language, even though they
> are using the same "instruction", MOV.
Yes, but that is truly the fault of the hardware designers. Intel have
a lot to answer for, and different commands using the same mneumonics is
a little foolish to say the least. But technically speaking, the
mneumonic code does map directly to machine code, due to the ambiguity
in this case, dependant on the operands.
> PROC and SEGMENT are part of MASM's syntax. What machine language
> instruction is it "directly representative" of?
>
PROC and SEGMENT are not assembly instructions, they are instructions to
the assembler to control the output and structure, they dont change the
actual code. They themselves are not part of the generic code, since no
808x6 processor has either instruction. They are part of the MASM set,
not the assembly language itself.
> Suprise! Optimization!
> MOV AX,0
> may be changed by an optimization pass to
> XOR AX,AX
>
> See?
>
Optimisation is an entirely different arena. It basically performs a
very compiler-like operation. It takes commands as an indication what
is wanted, and tries to create its own code to do so as efficiently as
possible. It should be noted that optimisation in an assembler can
always be turned off (unless the assembler sucks badly) to cause a
direct relationship between mneumonic and native code.
> >Your description of interpreter was closer. An interpreter is basically
> >a stream translater of a given code.
>
> Stream? Nope. Not always. Many interpreters are block interpreters.
> They'll read in a logical chunk of code and do 2 or more passes over it.
> Nothings says you *have* to make a one-pass-run-as-you-go interpreter.
>
Very true, but I was only trying to outline the differences to someone
who obviously knew nothing of the subject, but insisted on arguing his
point aggressively. Technically none of these definitions are bound,
they can all expand and implement features of each style whilst still
retaining their respective modus operandi. An interpreter could
technically compile each command before execution. An assembler can
generate code not directly defined in the source, thats just the way we
make 'em.
> >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.
>
> #!/bin/sh
> cd /opt/package/
> ./configure >/dev/null
> make>/dev/null
> exec ./foo $@
>
> Ugly, but hey, it works. :-)
Heh, I'll take your word for it :-P
> >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?
>
> Yup. It's more stuff to debug, it add extra processing that will bog
> the system down if you're doing other things that content for the same
> resouce (CPU for JIT vs CPU for streaming audio. You use a JIT-compiled
> app to do streaming audio, it gets worse).
>
> -- DN
Hmm, well I cant agree here. More stuff to debug? Yes, there is more
code for any given piece of software, as you would have to count the
runtime compiler as necessary to the execution. But, a runtime compiler
is not necessarily more fallible than a one-shot compiler, so as for
your more debugging argument... I dont think so. It would add extra
processing, but processing a well structured nano-code into native is
actually very simple and not processor intensive at all. Secondly, the
compilation only occurs when a new function is required by the system,
so it should only occur often when tasks are started or stopped. In the
case of streaming audio, if you were to start a new app for streaming
audio, firstly the audio couldnt start streaming until the runtime
compiler had finished creating the code, after which it would probably
not be needed for this task again, hence very unlikely to overlap.
Also, streaming audio would be prioritised by a good operating system as
requiring more than average resources (although it hardly does these
days). Next, clever usage of DMA could probably lower processor usage
to almost nothing, use two buffers, have the audio device read from one
while the other is being read from disk, then swap... its not
complicated, the concept of real time compilation from a "bytecode" like
source is a very good idea. You may be confusing the concept of runtime
compilation with the actual runtime compilers available, which are
admittedly not the best examples of the technology.
James
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Get ETH hardware address from user program
Date: 1 Sep 1999 05:04:53 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Low Hsin Yee <[EMAIL PROTECTED]>]
> I have try to get the ETH Hardware address from user program using
> ioctl(socket_fd, SICOCGARP &arpreq)
Have you tried SIOCSIFHWADDR? See /usr/include/linux/sockios.h.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Stefan Waizmann <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.development,linux.dev.kernel
Subject: Re: Getting the Ethernet ID from directly from the network card.
Date: Wed, 01 Sep 1999 12:08:17 +0200
Reply-To: [EMAIL PROTECTED]
Peter Samuelson wrote:
>
> [Vincent <[EMAIL PROTECTED]>]
> > I'm developping a driver that it must getting the Ethernet ID
> > directly on the network card.
>
> This is confusing. Are you developing a network driver? If so, we
> can't help you without knowing what the hardware is like.
Hi, I would also like to have a short program to get the (unique)
MAC-address of the ethernet card just for information. Or is there any
possibilty to have a look to this with existing means?
Stefan
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Get ETH hardware address from user program
Date: 1 Sep 1999 05:06:36 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Peter Samuelson <[EMAIL PROTECTED]>]
> Have you tried SIOCSIFHWADDR? See /usr/include/linux/sockios.h.
s/SIOCSIFHWADDR/SIOCGIFHWADDR/, sorry.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: select() and FD_SETSIZE
Date: 1 Sep 1999 09:50:44 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED]
In newsgroup: comp.os.linux.development.system
>
> Poll is superior because it has a size parameter (like, wow).
>
Uh... select does, too.
> You pass it a straightforward array of structs, a number specifying
> how many elements are in that array, and an integer representing a
> timeout in milliseconds.
>
> There is no messing around with fd_set bitmasks or struct timeval. No computing
> the highest descriptor number plus one.
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.
> Poll is better for threads too. If you divide a large set of file descriptors
> among threads, the problem with select is that in each thread, it has to skip
> over all the zero entries in the bitmask corresponding to descriptors that the
> thread is not handling. With poll, your array only contains file descriptors of
> interest, in any order you want.
poll() does handle sparse sets better, but dense sets poorer (except
perhaps now when Linux effectively does select() in terms of poll().)
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Date: Wed, 1 Sep 1999 11:03:34 +0000
On 1 Sep 1999, Olaf Klischat wrote:
>"Ben Gunter" <[EMAIL PROTECTED]> writes:
>
>> In /etc/inittab, there's a line like this:
>>
>> # Trap CTRL-ALT-DELETE
>> ca::ctrlaltdel:/sbin/shutdown -t3 -r now
>>
>> I think commenting that line out and running "init q" will have the effect
>> you're looking for.
>>
>
>Hmm.. not that I have much of an idea about linux system programming,
What does this example have to do with programming? 'If it ain't
clickety-click, it's programming'???
>but sometimes I come to the conclusion that, in the unix world, it is
>considered sane to hack some rather sensitive config file
>programmatically and be happy that it works somehow...
It's a _configuration_ file, for $DEITY's sake, just like you said! It
is _meant_ to be edited to suit your particular setup/situation!
And the use of 'hacking' instead of editing is just to make it sound
bad. What exactly do you mean? The above is not a trick of some sort, is
is documented and well-defined behaviour.
And text files are a lot less sensitive than a binary heap full of
pointers, IMHO. hdfsSetKeyRegExA(), wouldn't you call that
'programmatically hacking a rather sensitive config file?'
Sheesh.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
** 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
******************************
