Linux-Development-Sys Digest #131, Volume #7 Tue, 31 Aug 99 17:13:59 EDT
Contents:
Re: select() and FD_SETSIZE (Kaz Kylheku)
Re: why not C++? (Kaz Kylheku)
Re: Disabling control-alt-delete from a program (Lew Pitcher)
Re: why not C++? (Don Waugaman)
Linux real-time clock Y2K support ("Ted Pavlic")
Re: why not C++? (Kaz Kylheku)
Re: Jesus: the ultimate OS (Graffiti)
Re: Win95 is a bloody pain in th ass(after I installed linux)!! (Richard Wilson)
NFS caching (bill davidsen)
Re: LispOS? (Nix)
Re: write() (Dan Mills)
Re: why not C++? (NF Stevens)
Re: why not C++? (Andomar)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: select() and FD_SETSIZE
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 15:46:23 GMT
On Tue, 31 Aug 1999 17:08:03 +0200, 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. And if so, can one adjust the maximum value via the
>FD_SETSIZE-define ??
The select function sucks, use poll. In the new kernels, select is implemented
in terms of abstractions that are designed for supporting the poll function.
Poll is superior because it has a size parameter (like, wow). 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.
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.
------------------------------
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: Tue, 31 Aug 1999 15:55:05 GMT
On 30 Aug 1999 23:25:16 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>>On 29 Aug 1999 15:29:10 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>>>References are extremely important for use with operator overloading
>>>and templates.
>
>>These are non-essential reasons for their existence.
>
>Please explain, then, how to make operator overloading work without
>reference types or "compiler magic".
You mean how to make it work in the existing C++ that has references?
Clearly you can't. In order to make a copy construtor or assignment operator,
you have to obey the prescribed forms which call for references.
This could have been designed around pointers instead.
E.g.
Object copy(&original);
and
copy = &original;
The copy constructor would look like:
Object *Object::Object(const Object *rhs)
{
// ... copy operations go here ...
return this; // not *this, blech!
}
>It seems that you would prefer the sudden invocation of compiler magic
>in those instances when passing by reference is needed for correct
>semantics.
No, I'd prefer the & operator to make a pointer. What you have *now* is
compiler magic.
> I would tend to disagree - C++ has too many special cases
>already.
And among those special cases is the handling of references.
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 18:46:54 GMT
Look in your /etc/inittab for a line that looks like...
ca::ctrlaltdel:/sbin/shutdown -t5 -rfn now
Remove this line, and you have disabled the <ctl><alt><del> keysequence.
Change the line to run a different program (say
ca::ctrlaltdel:/bin/echo 'somebody hit ctl-alt-del' >/dev/console
and you change the action the key sequence invokes
If you are concerned about luser escapes, you might also disable
the abort keys in your X server (see /etc/XF86Config for details)
On Tue, 31 Aug 1999 18:41:36 GMT, [EMAIL PROTECTED] wrote:
>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
Lew Pitcher
System Consultant, Integration Solutions Architecture
Toronto Dominion Bank
([EMAIL PROTECTED])
(Opinions expressed are my own, not my employer's.)
------------------------------
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 10:03:20 -0700
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. The
>interpreter could be used to debug the code and then it could be compiled when
>there's reasonable evidence that it is acceptably bugless. Also the environment
>should support adding and fixing functions/classes as the program is running
>(i.e. no edit-compile-debug-cycle). This would reap many of the benefits of the
>dynamic language environments in terms of development speed. It's weird that
>even the leading compiler vendors have missed the option of using interpretation
>during development.
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 think your idea has a great deal of merit. GNU used to (still does?)
have a package called 'checker' which was intended to provide a runtime
environment for catching these kinds of errors at the point of infraction.
I'm not sure but there may have been a compiler switch which slightly
changed code generation to perform some of these basic checks inline.
The edit-compile-debug cycle could be shortened by using some form of
dynamic relinking, though keeping the lists of references that need to
be changed is a chore.
Another approach is to create a binary rewriting tool that inserts checks
for memory-use problems directly into an executable. Unfortunately, this
method is patented by the Purify folks.
--
- 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..." | <><
...When the doc start's whistlin' "Happy Trails," it really tends to
take the wind out of your sails..... - Steve Taylor
------------------------------
From: "Ted Pavlic" <[EMAIL PROTECTED]>
Subject: Linux real-time clock Y2K support
Date: Tue, 31 Aug 1999 12:17:45 -0400
Does anyone know of an application for Linux that will provide protection
against real-time clocks that are not Y2K-compliant? I know of a DOS TSR
that sort of acts like a wrapper around the BIOS, if there is a Y2K issue
with the RTC, and ends up making corrections where necessary. Is there
anything like this for Linux?
------------------------------
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: Tue, 31 Aug 1999 15:56:30 GMT
On 30 Aug 1999 23:44:08 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>However, considering the difficulty of creating code that exercises the
>compiler this way, compared to the ease of creating code that dereferences
>a NULL pointer, I would say that C++ references pass the "Murphy" test
>with flying colors.
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.
------------------------------
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:55:35 -0700
In article <[EMAIL PROTECTED]>,
James Andrews <[EMAIL PROTECTED]> wrote:
[snip]
>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.
Wanna bet?
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.
PROC and SEGMENT are part of MASM's syntax. What machine language
instruction is it "directly representative" of?
Suprise! Optimization!
MOV AX,0
may be changed by an optimization pass to
XOR AX,AX
See?
>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.
>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. :-)
>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
------------------------------
From: [EMAIL PROTECTED] (Richard Wilson)
Subject: Re: Win95 is a bloody pain in th ass(after I installed linux)!!
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Aug 1999 15:24:30 GMT
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.
One of the overlooked nasties of the DOS/Win world is its view of the
partition table. DOS/Win expects the physical partitions to be
numbered in the order they are seen looking upward from cylinder 0.
Real operating systems (Linux for one) appear to number the physical
partitions by the order of creation regardless of where they sit on
the disk.
This distinct difference nailed me a year or so ago when I ventured
forth into linuxland. When I first built my partitions strictly for
DOS/Win I created a first physical partition then immediately created
the extended partition and then a logical. The logical would be shared
between various incarnations of bootable DOS/Win physical partitions.
Then I added another physical partition adjacent to the first
partition for another bootable copy of DOS/Win. All was well with this
as DOS/Win's fdisk would see the first bootable physical partition as
partition #1, the second bootable physical partition as #2, the
extended partition as #4 and the logical partition as #5.
Along came Linux using its fdisk. I created a third physical partition
for Linux and a logical partition for swap. Linux fdisk dutifully
rewrote the partition table the way it "should" be, that being, in
chronologically created order. The first-created DOS/Win physical
partition as #1, the next-created extended partition as #2, the second
DOS/Win partition as #3 and the Linux partition as #4. The DOS/Win
logical #5 and the linux swap #6.
Well, DOS/Win said an instant adios to the second bootable DOS/Win
partition since in its eyes it was supposed to be partition #2 but
partition #2 was now the extended partition and that was simply "not
right!" That was that. Any DOS-based fdisk choked at the "incorrect"
partition table and refused to proceed.
I could still boot physical partition #1 and even access the DOS/Win
logical partition so it wasn't a complete disaster. But that second
physical DOS/Win partition was unreachable by any DOS means.
I hope you've not fallen into that death trap. If you had a second
physical partition with DOS/Win data on it that My Computer wants to
see... it won't. I wouldn't expect it to freeze though but who knows.
A thought... You may want to try a Linux-based disk image copy of the
affected physical DOS/Win partition to a logical partition (if such a
program exists) just to see if DOS/Win can then see the data. Worth a
shot if it can be done.
Richard
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.networking
Subject: NFS caching
Date: 31 Aug 1999 19:48:35 GMT
Has anyone done anything to reduce network traffic between client and
server when the data on the server is known not to change? I'm being
very vague because I don't want to scare off any good solutions.
What I'd like to do is set aside a GB or so of local disk as a cache
area for that data which is known not to change. Unfortunately I need a
"per mount" solution, since there are other mount points which change
normally.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"So let it be written, so let it be dumb." Pharaoh Dufus the last...
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: LispOS?
Date: 31 Aug 1999 20:55:38 +0100
Chris Mahmood <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Depeche) writes:
>
> > I, too, think that this is a sad affair. I wonder if there would be
> > support for a true LISP based openSource reimplementation.
> Well, how much longer will it be before we can just boot emacs?
`ln /usr/bin/emacs /sbin/init' is your friend.
;}
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Oxford
breed of `conference American'.
------------------------------
From: Dan Mills <[EMAIL PROTECTED]>
Subject: Re: write()
Date: Tue, 31 Aug 1999 15:50:23 +0100
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,
IIRC When in the kernel the system will use co-operative multi-tasking
to allow other tasks to run while it waits on disk io.
Any time you see a call to schedule() it is possible for the kernel
to task switch. For example if a disk driver is waiting on a seek it
will cause the scheduler to be invoked.
Obviously you must ensure that all necassary locks are released before
making this call, or you risk a deadlock.
Also you cannot call schedule () from inside an interrupt handler.
Disclaimer - I am not a kernel hacker!
Regards, Dan.
--
The email address **IS** Valid, do **not** remove spamblock!
------------------------------
From: [EMAIL PROTECTED] (NF Stevens)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Tue, 31 Aug 1999 20:09:03 GMT
[EMAIL PROTECTED] (Don Waugaman) wrote:
[snip]
>In other words, the statement "references must be non-NULL" fails the
>Machiavelli test.
>
>However, considering the difficulty of creating code that exercises the
>compiler this way, compared to the ease of creating code that dereferences
>a NULL pointer, I would say that C++ references pass the "Murphy" test
>with flying colors.
I disagree with this. The places where C can introduce a null pointer
are exactly the same places where a null reference would creep in in
C++. If you can make all you C++ references point to existing variables
then the equivalent C construction (which is to take the address of
an existing variable) has no possibility of introducing a null pointer.
However in situations where you are dealing with pointers whose
value must be changed (e.g. because they are part of some changing
data structure) then in a C++ program you must use the deference
pointer to reference construction used in my previous post. My
argument is that these situations using a reference rather than
a pointer gives you no absolutely no guarantee of pointing to
a valid object.
Norman
------------------------------
Date: Tue, 31 Aug 1999 19:11:53 +0200
From: Andomar <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
> In the face of the new possibilities for error, the static diagnosis of
>
> foo(NULL);
>
> is a worthless consolation prize.
Agreed. I never use references for that reason.
------------------------------
** 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
******************************
