Linux-Development-Sys Digest #142, Volume #7 Thu, 2 Sep 99 10:13:49 EDT
Contents:
Re: select() and FD_SETSIZE (David Schwartz)
Re: unique machine ID for Linux on ix86 platform? (David Schwartz)
Re: TAO: the ultimate OS (Peter T. Breuer)
set up c++ development environment
Scheduling in Kernel 2.2 (Christoph Pleger)
Re: select() and FD_SETSIZE (Peter Samuelson)
Re: select() and FD_SETSIZE (Ton Nijkes)
Re: IDE for c++ dev? (Ian Thompson Bell)
Re: Disabling control-alt-delete from a program (Emile van bergen)
Re: History (Stephan Houben)
Re: Linux on RS/6000 (Frederick Paepke)
Re: Dual Modem Support (Brandon Szalai)
Re: TAO: the ultimate OS (Theodore Y. Ts'o)
LINUX AND COREL (J Mars)
Re: IDE for c++ dev? (Toby Haynes)
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: select() and FD_SETSIZE
Date: Thu, 02 Sep 1999 00:42:48 -0700
Phil Howard wrote:
> I've done a lot of programming with select(). The way you characterize
> it just isn't so. If your use of the fd_set macros is done without
> checking the proper bounds (or check them when you get fd numbers to
> work with) then it's a programmer error, not a system call interface
> design issue.
Okay, how do you know what the proper bound is? Do you just guess? Do
you assume that '8*sizeof(struct fd_set)' is correct? Do you assume the
'FD_SETSIZE' will be defined?
> You can just as easily cause such errors by passing an
> invalid argument to poll() or by bad programming that fails to check
> the bounds to your fdarray.
Yes, but with poll, you know what the size of your array is, since you
allocated it. With select, it's hidden inside impenetrable macros.
Please tell me how you, portably, determine whether or not you can
safely call FD_SET with a particular file descriptor value.
> Both select() and poll() cannot protect
> against bad programming (nor should they try to).
Agreed. But it's a joke to claim that 'select' is portable if you can
never portably know whether or not a particular call to FD_SET will blow
up.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: unique machine ID for Linux on ix86 platform?
Date: Thu, 02 Sep 1999 01:34:58 -0700
Actually, that's the P3. And it wouldn't help you anyway -- how could
you read it?
<sarcasm>I suppose you could ask each person to bring in their P3 and
drop it into your 'serial number reader' and then if it matched you
could give them the software.</sarcasm>
But ultimately, you have to ask something under the user's control what
the serial number is.
DS
Matthew Carl Schumaker wrote:
>
> This may be slightly off topic but don't/didn't Intel PII come with a
> serial number burned into the chip that was readable for exactly this type
> of purpose? I remember they got yelled at for privacy reasons but did
> they ever remove it?
>
> just a thought
>
> Matthew Carl Schumaker
> UPAC Lights Administrative Chairperson
> [EMAIL PROTECTED]
> veni, vedi, velcro
> I came, I saw, I stuck around
>
> On 5 Aug 1999, Jens Kristian S�gaard wrote:
>
> > [EMAIL PROTECTED] (Remco van den Berg) writes:
> >
> > > > - tying software to an Ethernet address fails when the Ethernet
> > > > address changes (newer faster card, broken card, etc).
> >
> > > I think the Ethernet MAC address could be an option, but isn't it possible
> > > to change that too?
> >
> > He already mentioned MAC-addresses. And yes, on some (more expensive)
> > NIC's, you can alter the MAC-adress from software.
> >
> > > The problem is that I want to make some software only for internal Philips
> > > usage. The software is confidential. That's why.
> >
> > Mark it confidential? - or haven't you got trust in the users?
> >
> > Or you could consider to have the software run on a server, to which
> > will connect to use the program. This ensures, that the software will
> > not be duplicated...
> >
> >
> > --
> > Jens Kristian S�gaard,
> > [EMAIL PROTECTED] -- http://soegaard.hypermart.net/
> > S�ger du noget? -- http://www.google.net/
> > -- At fejle er menneskeligt; totalt sammenbrud kr�ver en computer
> >
> >
------------------------------
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: 2 Sep 1999 09:18:04 GMT
Reply-To: [EMAIL PROTECTED]
Christopher B. Browne ([EMAIL PROTECTED]) wrote:
: >: 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,
"the resulting program", I meant.
: >: it will never do anything to anything, and thus it can not be a virus.
: >: If it is not a virus, then it will harm the system (sandboxed!) and
: >: thus it is a virus.
: >
: >yes, a contradiction, its very similar to the halting proof by
: >design. I'd say you've got it.
: ... But it misses the "Trojan Horse" approach, where the would-be
: virus refuses to activate the "bad stuff" until it can establish a
: communications link to a provably remote site (e.g. - "home") so as
: to have reasonable evidence that it is running in a "real" system
: rather than in a sandbox.
The proof above considered a virus checker that checks programs that
take an input (in the case constructed, the input is its own code).
I.e. trojans.
I was sloppy with writing it down, but I could do it again with
p(X) instead of p. I.e. suppose we have virus checker V(p) that
checks if EX.p(X) will corrupt the system ("p is a virus") ...
The proof is valid for programs with io. You can't write a program to
reliably detect trojans or viruses.
My comment was that the proof is valid even in the presence of the
sandboxing concept. The proof goes through when the system is arranged
in hierarchies. You can't write a program that will reliably detect a
virus, even if you can execute that virus in a sandbox so it doesn't
harm you. Any program that detects some viruses must fail to detect
others (notably the trojan constructed in the proof).
I'm not sure that's the interesting part, or if there is an
interesting part ...
Peter
------------------------------
From: <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: set up c++ development environment
Date: Thu, 02 Sep 1999 09:31:04 GMT
i am learning c++. i want to do c++ program under linux. what packages
(rpm) do i need? what environment variable i need to set? and how i
compile the source code?
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Christoph Pleger)
Crossposted-To: comp.os.linux.development.apps
Subject: Scheduling in Kernel 2.2
Date: 2 Sep 1999 09:26:18 GMT
Hello,
What has happened with the scheduling under Kernel 2.2?
I had compiled the following program under Kernel 2.0. The program - as intended
- switched the context between two processes:
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
#include <unistd.h>
#include <sched.h>
#include <stdio.h>
#define DPRINTF(str) { printf(str); fflush(stdout); }
#define LOOPS 10
struct sched_param schedparam;
pid_t Children[2] = {0,0};
int min,max;
void server(void)
{
schedparam.sched_priority = max - 5;
sched_setscheduler(0,SCHED_FIFO,&schedparam);
sched_yield();
while (1)
{
DPRINTF("server\n");
sched_yield();
}
}
void client(void)
{
int i;
schedparam.sched_priority = max - 5;
sched_setscheduler(0,SCHED_FIFO,&schedparam);
sched_yield();
for (i = 0;i < LOOPS;i++)
{
DPRINTF("client\n");
sched_yield();
}
kill(Children[0],SIGKILL);}
void main(void)
{
min = sched_get_priority_min(SCHED_FIFO);
max = sched_get_priority_max(SCHED_FIFO);
schedparam.sched_priority = max;
sched_setscheduler(0,SCHED_FIFO,&schedparam);
if ((Children[0] = fork()) != 0)
{
if ((Children[1] = fork()) == 0)
{
client();
_exit(0);
}
}
else
{
server();
_exit(0);
}
waitpid(Children[0],NULL,0);
waitpid(Children[1],NULL,0);
}
After switching to Kernel 2.2 the program was recompiled. When I let it run
now, the server-process stays in its endless-loop and the client-process is
never reached. What can be the reason for that? Was the scheduling changed in the
kernel?
Then I tested the following:
void main(void)
{
min = sched_get_priority_min(SCHED_FIFO);
max = sched_get_priority_max(SCHED_FIFO);
schedparam.sched_priority = max;
sched_setscheduler(0,SCHED_FIFO,&schedparam);
if ((Children[0] = fork()) != 0)
{
if ((Children[1] = fork()) == 0)
{
switch (sched_getscheduler(0))
{
case SCHED_OTHER: printf("client: SCHED_OTHER, "); break;
case SCHED_FIFO: printf("client: SCHED_FIFO, "); break;
case SCHED_RR: printf("client: SCHED_RR, "); break;
default: break;
}
sched_getparam(0,&schedparam);
printf("%d\n",schedparam.sched_priority);
// client();
// _exit(0);
}
}
else
{
switch (sched_getscheduler(0))
{
case SCHED_OTHER: printf("server: SCHED_OTHER, "); break;
case SCHED_FIFO: printf("server: SCHED_FIFO, "); break;
case SCHED_RR: printf("server: SCHED_RR, "); break;
default: break;
}
sched_getparam(0,&schedparam);
printf("%d\n",schedparam.sched_priority);
// server();
// _exit(0);
}
waitpid(Children[0],NULL,0);
waitpid(Children[1],NULL,0);
}
This program gave the following output:
client: SCHED_FIFO, 99
server: SCHED_FIFO, 99
How is it possible that - in spite of SCHED_FIFO and equal priority - the
client makes its output before the server, though the server was created
before the client?
In Kernel 2.0 the server was started before the client.
Christoph
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: select() and FD_SETSIZE
Date: 2 Sep 1999 05:01:17 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Kaz Kylheku <[EMAIL PROTECTED]>]
> I think we can things up neatly with this table:
>
> Bell Labs intellectuals Berkeley dope-smokers
> -------------------------------------------------------------
> Bourne shell C shell
^^^^^^+Korn
> poll select
> write talk, talkd
> memcpy and memmove bcopy
> termios sgtty
terminfo, almost O(1) termcap, O(N)
runlevel directories runlevel files
version number as roman numeral version number as prefix
big- or little-endian PDP-endian
Kidding on that last....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Ton Nijkes)
Subject: Re: select() and FD_SETSIZE
Reply-To: [EMAIL PROTECTED]
Date: Thu, 2 Sep 1999 08:44:53 GMT
On Thu, 02 Sep 1999 05:29:52 GMT, Phil Howard <[EMAIL PROTECTED]> wrote:
[snip]
> What I don't like about poll() is that it doesn't make expanding the
> size of the fd array any easier. I either have to allocate a giant
> fd array in anticipation of the maximum number of fds I might use, or
> dynamically allocate and copy the contents around to change the size.
What about realloc()?
> The poll() documentation does not indicate if the revent members have
> to be cleared to 0 before calling poll(). And the SVR4 form of poll()
> uses INFTIM for timeout for infinite time, whereas the Linux form uses
> a negative number (according to documentation). This might still be
> a portability issue.
>From the poll() man page on NCR MP-RAS SVR4 UNIX:
"If the value of timeout is INFTIM (or -1), poll blocks until a requested
event occurs or until the call is interrupted."
Using -1 for timeout seems pretty portable.
Greetz,
Ton.
--
================================================================================
//
// Ton Nijkes Email: [EMAIL PROTECTED] /
//|\ || Murphy Software BV, [EMAIL PROTECTED]
//||\\|| P.O. Box 285, Voice: +31 (0)53 4320055
|| \|| 7500 AG Enschede, The Netherlands Fax : +31 (0)53 4326595
================================================================================
------------------------------
Date: Thu, 02 Sep 1999 11:43:18 +0100
From: Ian Thompson Bell <[EMAIL PROTECTED]>
Subject: Re: IDE for c++ dev?
Nix wrote:
>
>
> After all, there is nothing that emacs cannot do. And that's
> official.
>
Apart from be intuitive you mean?
Ian
------------------------------
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: Thu, 2 Sep 1999 12:28:18 +0000
On 2 Sep 1999, Olaf Klischat wrote:
>Emile van bergen <[EMAIL PROTECTED]> writes:
>
>> 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'???
>
>Is there a misunderstanding here?
Yes. Very much so. I'm sorry, I was in a bad mood, skimmed through the
post, thought that I saw someone who viewed editing (manually)
/etc/initab as some kind of programming and considered touching this
file a bad idea.
I got it completely the wrong way around, the poster made exactly the
point I would make (and you as well...)!
>The original poster said that what he wanted to do was "Disabling
>control-alt-delete from a _program_". Which, in this case, would mean
>to do all these inittab modifications "silently" via fread()/fwrite()
>or something directly from the program.
>
>OK, maybe that's not so much a problem with inittab as it would be
>with, say, /etc/profile, because inittab has a fairly fixed format,
>but nonetheless...
>
>I for myself wouldn't want to have my config files modified by
>something other than myself (that is, my favorite text editor :)
>). Isn't it "common sense" in unix to _edit_ configuration files
>manually or maybe with some authorized configuration tool only? If you
>don't follow that rule, there's always the chance that you break
>something, IMVHO.
Yes, exactly. I'd hate having joe random's app mess with configuration
files that don't belong to joe random's app, unless via a well defined
interface provided by the program to which the configuration file(s)
belong.
>> >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...
... and he's quite right; application A shouldn't touch application B's
files, it shows lack of social skills ;-). I'm only glad I don't see to
much evidence in support of his conclusion (yet)...
Again, sorry for my misguided flame!
--
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
------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: History
Date: 02 Sep 1999 14:19:59 +0200
[EMAIL PROTECTED] (Lew Pitcher) writes:
> On Thu, 02 Sep 1999 03:31:15 GMT, Julius <[EMAIL PROTECTED]> wrote:
>
> >The History of Linux from the beginning and how it's working compare with
>
> >other Operating Systems.
>
> ?????????????
Why the ??????? ?
The beginning of Linux hasn't really started yet and so far it's the only
*real* Operating System. ;-)
So the "History of Linux from the beginning and how it's working
compare with other Operating Systems" is indeed best summarized with
an empty line.
Stephan
------------------------------
From: [EMAIL PROTECTED] (Frederick Paepke)
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: Thu, 02 Sep 1999 12:58:42 GMT
[EMAIL PROTECTED] (Magnus Larsson) wrote:
>I wanna start an organized Linux development on the RS/6000. Anyone
>interested?
>
>//Magnus
I know nothing about the development side of things, but I may soon have some
older MCA RS/6000s (both PowerPC and Power2?) that I can donate to someone
serious about coding.
Please include me in on any future discussion about this port.
Frederick.
------------------------------
From: Brandon Szalai <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.unix.programmer
Subject: Re: Dual Modem Support
Date: Thu, 02 Sep 1999 09:19:10 -0400
I have a Diamond SupraSonic II dual modem in my machine. What I had to end up
doing is buying a PS/2 mouse and port and install it. Had to get rid of my
serial mouse. I also had to disable PnP in my computer bios. I was having IRQ
conflicts between my serial mouse and "com 3". Both modems work fine for me. My
first modem is ttyS0 and my second is ttyS1. Hope this helps...
Brandon Szalai
Anonymous wrote:
> Hello,
>
> Is anyone have any idea, source or link to the info on how to make
> dual-modem ppp connection in Linux /
> Unix ? or through writing our own program ? how is the concept behind ?
> any RFC for this ?
>
> Ie, use two modem to dial-up to the same site to speed up the tranfer rate,
> as in win95 multi-link support
> in dial-up networking.
>
> Thank in advance
>
> --
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> :< [EMAIL PROTECTED]
> :< [EMAIL PROTECTED]
> :< [EMAIL PROTECTED]
> :< [EMAIL PROTECTED]
> :< [EMAIL PROTECTED]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: [EMAIL PROTECTED] (Theodore Y. Ts'o)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 02 Sep 1999 09:41:45 -0400
[EMAIL PROTECTED] (Peter Samuelson) writes:
> > I just pointed out in a recent message..its obvious you can have some
> > files that are read only to some applications, and write to others.
> > what you are telling me is that it could become slightly more
> > complicated than an existing system. but this is quite different
> > than the claim of impossibility.
>
> 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.
There's another tradeoff; between security and ease of use. The
question is, how do you configure your sandbox? You either ask the user
to configure it, in which case you lose because the user won't know how
to answers the questions correctly, and it will be horribly complex or,
you can ask the program which is running, which you can't do because
it's not trustworthy.
You could posit that the OS could look over the code and figure how the
sandbox should be configured based on what the requirements of the
applet are, but how does the OS determine what are legitimate
requirements and what are bogus requirements? Sure you can block out
really obvious ones, like "I need raw access to the disk so I can format
it", but more subtle ones like the application claiming "I need write
access to the spreadsheet so I can update some data" --- is it really
updating data, or is it destroying data? Or is it installing an
application macro virus? Having the OS figure it out without asking the
user is tantamount to trying to solve the halting problem.
The other approach which has been tried is code signing --- but that
assumes that the code signers are trustworthy. And more recently, there
have been a number of cases by Microsoft, Compaq, and HP, where they
signed some code which itself could be used improperly, and with the
right data sets the code could destroy your system. Sure, these were
"Bugs", but assuming (by assertion) that your system will be BugFree(tm)
shows an incredible amount of naivete --- it's not unlike Bill Gates
claiming that Microsoft Software has no bugs. (according to him, they
just have "issues" :-)
The final observation I will make is that Vladimir's "we'll just make
some files read-only" also shows an amazing amount of naivete.
Read-only compromise (of strategic planning data of a company, for
example) can often do just as much damage as other kinds of damage ---
after all, even if a virus destroys your data, assuming that you have
competent sysadmins, you'll have backups. But with a read-only
compromise of sensitive data, you may never know what hit you until it's
too late.
But, as I started this whole posting with ---- this completely begs the
question of how do you configure the sandbox in the first place? How do
you know which files (or objects) an application should be given write
access, and to which an application should be only given read access?
What (if any) network connections should the application be allowed to
open? Is the application allowed to throw up a window? Is the
application allowed to grab keyboard focus? So many questions --- and
no way to answer them securely.
Not specifying such troubling, niggling little details is part of the
hand-waving and arm-waving which is going on here.
- Ted
------------------------------
From: J Mars <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: LINUX AND COREL
Date: Thu, 02 Sep 1999 13:31:06 GMT
There are talks that Corel will bring out a Linux Wordperfect suite and
O/S. Did anyone tried this?.
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Subject: Re: IDE for c++ dev?
Date: 02 Sep 1999 09:14:13 -0400
Ian Thompson Bell <[EMAIL PROTECTED]> writes:
> Nix wrote:
> > After all, there is nothing that emacs cannot do. And that's
> > official.
> Apart from be intuitive you mean?
Emacs *is* reasonably intuitive once you discover the following
routines to tell you about where, what and how.
C-h i RET
C-h a RET <part-of-command> RET
M-x apropos RET <anything-you-care-to-mention> RET
M-x apropos-documentation RET <anything-you-care-to-mention> RET
After that, you realise you can reconfigure anything at all, so if you
find the interface confusing, you can change it or build your own
menus.
Maybe there could be an effort to create an even simpler starting menu set
for people completely new to Emacs, or maybe this already exists? If
not, it probably should be done to increase the number of converts! :-)
Cheers,
Toby
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
** 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
******************************
