Linux-Development-Sys Digest #137, Volume #7 Wed, 1 Sep 99 19:14:32 EDT
Contents:
Re: select() and FD_SETSIZE (Kaz Kylheku)
Re: PROPOSAL: A secure, simple NIS replacement ([EMAIL PROTECTED])
Re: why not C++? (Tristan Wibberley)
Re: where are packets created? (Villy Kruse)
Re: LispOS? (Chris Mahmood)
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
RPC in Linux ("natarajs")
Video Camera on Linux... (Gandolf)
Re: PROPOSAL: A secure, simple NIS replacement (Peter T. Breuer)
Re: Linux on RS/6000 (BSD Bob)
Re: Linux on RS/6000 (BSD Bob)
Shutdown Problem ("stan168")
Re: CDROM: Illegal Request (Dr. Peer Griebel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: select() and FD_SETSIZE
Reply-To: [EMAIL PROTECTED]
Date: Wed, 01 Sep 1999 18:36:33 GMT
On 1 Sep 1999 09:50:44 GMT, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>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.
The problem is that the size argument is brain-damaged. If you want
to select on descriptors 256 through 511, you have to specify 512
as the size, even though the first 256 descriptors are ignored.
Allocating the fd_set is cheap because when it is done in automatic storage.
Allocating automatic storage is done on the stack simply by moving the stack
pointer. The fixed size of the object actually helps you there; if it were
variable, you would have to use dynamic allocation or some hack like alloca().
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: Wed, 01 Sep 1999 15:25:18 GMT
[EMAIL PROTECTED] wrote:
> On Wed, 25 Aug 1999 14:43:01 GMT, [EMAIL PROTECTED] wrote:
> > and I don't WANT to maintian another database.
>
> That's why NIS+ exists.
> What's so tough about typing
>
> "nispopulate -F passwd"
> after you add a user?
> There is basically no additional maintainance after you get it set up,
> if all you want to do is "a secure /etc/passwd distribution mechanism"
1. NIS is not secure.
2. NIS does not allow me to arbitrarily string clients/servers so that I
can build up a user database in a heirarchy (NIS+ does this, but is even
more footprint-intensive than NIS.
I may just have to write the damn thing, since no one seems to
understand why it's interesting. As a UNIX sysadmin on-and-off of 10
years, I know that *I* would want this thing!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Wed, 25 Aug 1999 03:11:16 +0100
Reply-To: [EMAIL PROTECTED]
Tristan Wibberley wrote:
>
> What trigraph would you use for that symbol,
> \\' maybe.
>
> C = A \\'x B;
> C = A \\'. B;
Doh, trigraphs use ? don't they, and ' is already used.
??. then since it's an alternative to using a method.
C = A ??.x B;
C = A ??.. B;
This is really nasty *<:o) - but elegant in it's way. It'll probably
never happen anyway.
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: where are packets created?
Date: 1 Sep 1999 18:21:40 +0200
Ken Booth <[EMAIL PROTECTED]> wrote:
>TCP/IP Illustrated (2 volumes), by W. Richard Stevens and Gary R. Wright.
You're missing the third.
--
Villy
------------------------------
From: Chris Mahmood <[EMAIL PROTECTED]>
Subject: Re: LispOS?
Date: 01 Sep 1999 01:54:15 -0700
Nix <$}xinix{[email protected]> writes:
> 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.
you meant 'ln /usr/lib/emacs/20.3/yow /sbin/init', right?
-ckm
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 20:02:19 GMT
In comp.os.misc Theodore Y. Ts'o <[EMAIL PROTECTED]> wrote:
: Indeed, and sandboxes aren't new either, and even predate Java.
the general principle imho has not been fully/adequately
explored.
: The limitations of sandboxes are also well known; either you make the
: sandbox too limiting, in which case you can't do anything interesting,
: or you make the sandbox too big, in which case the virus or other
: hostile code can do too much damage.
I think this is a false dichotomy. I think when a designer runs into
this quandary it reflects a lack of imagination & engineering
ingenuity.
: For example, all user applications can't just run in a sandbox, because
: they need access to the user's data files. So if you have hostile code
: embedded in a Microsoft Word macro, for example, the fact that it's
: running in a sandbox won't help you. You could restrict things so that
: an application only has access to its own data files --- i.e., a word
: processor has access to only its own word processor files, and a spread
: sheet only has access to its file. But now you can't embedded a
: spreadsheet in a word processor document!
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.
yes, that is exactly what I am proposing: a system in which all
applications run in a sandbox-- even key elements such as drivers.
I believe this is not only desirable but inevitable.
: This sorts of tradeoffs happen all the time when you're dealing with a
: sandbox architecture, and as always, the devil is in the details.
: Simply saving your arms and saying that "the problems will go away
: because I'm using a sandbox" is rather specious.
let us agree on this then:
the problems will not go away unless the sandbox is designed in
an ingenious way that transcends all prior attempts lacking in
imagination.
let us also agree that while such a thing may perhaps be
difficult to achieve, it certainly is not going to create
itself.
for those who wish to participate in its construction, plz
sign up for the mailing list below.
for those who think it is impossible, remember the quote,
"the impossible just takes longer"... <g>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 19:56:34 GMT
In comp.os.misc Peter T. Breuer <[EMAIL PROTECTED]> wrote:
: C'mon folks, don't be dense. He means a virtual unix provided to the
: user to play in. That's a sandbox.
in a sense.. I don't really like unix as a future OS, but that would
be an example..
: 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.
well I would rather you use these concepts as metaphors for how
the new OS would work.
: 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.
exactly.
: I'm not sure I followed the quoted impossibility proof for virus
: checking, however! Something appeared to have been left out.
maybe someone remembers the reference. it was in American Mathematical
Monthly around the early 90s or so.
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.
yes, a contradiction, its very similar to the halting proof by
design. I'd say you've got it.
: 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.
as I say, concepts such as "a virus calls subroutine check_virus"
is not possible if that subroutine is not available for that
program to call. the subroutine is undefined.
my other point is that a program that POTENTIALLY corrupts the
OS is a virus under a reasonable definition--whether it does
so in practice (a particular run) or not. it is possible to
verify a program has no potential to corrupt the OS using
the sandbox principle you yourself outlined above.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 19:50:53 GMT
In comp.os.misc 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.
roughly.. I agree.. but notice how it was pasted on after
most of the OS was already developed.
: 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.
unix is not easy for the nonliterate user to handle. quite to
the contrary I would say it is "nonliterate hostile". moreover, unix
was not designed from the top down to have these constraints.
I'm suggesting building a new OS in which the sandbox concept
is paramount & drives most aspects of the design rather than
being pasted on as a hurried/desperate afterthought/bandaid.
I'm suggesting a system in which sandboxes do
not have to be specially configured-- they are the natural
state of the system.
notice how easy it is to miss some aspect
of the unix "sandbox" in attempting to configure one. you keep
throwing additional steps that must be taken to create one
in unix. and we both know the steps you are alluding to
do not truly create a bulletproof/airtight sandbox to
borrow your own terminology.
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.
"somewhat crude"-- exactly. an absolutely crucial aspect
of the system is "somewhat crude"..?? huh? exactly.
the concepts of paramount importance
are poorly & incompletely implemented imho. implementing
it all in a streamlined fashion is, therefore, to a large
degree, revolutionary.
: Most of the argument of this thread centers around your goal of making
: viruses impossible by design.
its one topic I've decided to focus on which respondents either
laternatively claim has already been done or is impossible. present
company not excluded.
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.
totally disagree. what we have today are systems that require the
absolute utmost care in attempting to create virus proof environments
and the utmost ingenuity of the system administrator. imho win95
does not even have such an environment whatsoever. I agree with you
the concepts have been feebly explored to date. you vastly
exaggerate their ability to restrict viruses esp. in a user-friendly
OS such as windows.
: 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.
its a goal I believe is achievable, exactly what you say, an
airtight, bugless system. I was hoping to collaborate with other
people who recognize it as a theoretical possibility, and were
cognizant of what I consider quite obvious and glaring
defects of existing systems. obviously if everyone is satisfied
with existing systems as the pinnacle of software engineering,
then I'm just a "mad programmer" I guess.
I didn't intend to hand it down
from the mountain like moses & his tablets, but apparently from
posts out here thats what everyone expects, so oh well, I guess I
will just have to keep "chipping away"..
(for those other than PS who have that nagging suspicion I am
describing something that could exist, please sign up for
the mailing list below dedicated to new OS trends. tx..)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: "natarajs" <[EMAIL PROTECTED]>
Subject: RPC in Linux
Date: Wed, 01 Sep 1999 17:00:48 GMT
We are trying to port an RPC server to Linux from Solaris.
Before we start promising anything, i would like to know if RPC
libraries/support
is available under Linux. Weare talking about rpc_* libraries, xdr
libraries and include files..etc
the original rpc program was generated using sun's "rpcgen" and then
handtweaked
after that.
Any comments/suggestions would be greatly greatly appreciated.
nataraj/.
[EMAIL PROTECTED]
--
Posted via Talkway - http://www.talkway.com
Exchange ideas on practically anything (tm).
------------------------------
From: Gandolf <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Video Camera on Linux...
Date: Tue, 31 Aug 1999 16:31:03 GMT
Has anyone been successful in attaching either a parallel port or
USB port based video camera to a Linux system ? I am interested in
which, what software/drivers and what it took to pull it off.
Pls rply to: [EMAIL PROTECTED]
Thanks.
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Peter T. Breuer)
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: 1 Sep 1999 21:43:02 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
: [EMAIL PROTECTED] wrote:
: > On Wed, 25 Aug 1999 14:43:01 GMT, [EMAIL PROTECTED] wrote:
: 1. NIS is not secure.
And so what? I have never understood this hooha. If somebody really
wants to spend his time cracking user passwords instead of asking me
for a login, good luck to them. And there are far easier ways to get
passwords than cracking public encryptions. Just monitor the net for
pop3 from windows machines, for a start!
: 2. NIS does not allow me to arbitrarily string clients/servers so that I
: can build up a user database in a heirarchy (NIS+ does this, but is even
Eh, yes it does? You can distribute nis databases from master to
slave servers. That's what I do anyway. What I hate doing is the reverse ..
alterations in the databases have to be passed directly to the master.
: more footprint-intensive than NIS.
Amen (shudder!).
: I may just have to write the damn thing, since no one seems to
: understand why it's interesting. As a UNIX sysadmin on-and-off of 10
: years, I know that *I* would want this thing!
Can one pass nis down cipe yet? Now that would be secure, in whatever
sense you mean.
--
Peter
------------------------------
From: BSD Bob <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: 1 Sep 1999 20:46:15 GMT
In comp.unix.aix Dave Marquardt <[EMAIL PROTECTED]> wrote:
> [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.
Any chance something like that would run on an old 7012/220 machine?
Bob
------------------------------
From: BSD Bob <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.powerpc,comp.unix.aix
Subject: Re: Linux on RS/6000
Date: 1 Sep 1999 20:49:24 GMT
In comp.unix.aix Peter Samuelson <[EMAIL PROTECTED]> wrote:
> [Dave Marquardt <[EMAIL PROTECTED]>]
>> There's a company called Yellow Dog that's selling Linux for RS/6000.
> All RS/6000's are not created equal -- it is really a brand name, not a
> model number. Yellow Dog Linux claims to run on two of IBM's
> PowerPC-604e/PCI-based models: the 43P-150 and the F50. There are a
> *lot* of unsupported models -- some higher-end, a couple lower-end, and
> lots obsolete. Among the lower-end/obsolete models are a couple with
> PCI busses but most have Micro Channel, and anything more than about
> four years old has POWER or POWER2 chips in them rather than PowerPC.
> Now I doubt the Linux PPC folks are interested in trying to write
> support for either MCA or non-PowerPC RS/6000's, which account for
> many, many old IBM boxes out there.
Having one of those older POWER things 7012/200 and no AIX (dumpster
surplus special machine), what can the home hobby unix type do to
find an AIX (3.x or 4.x) that will run on the old dinosaur.
It would have been neat if Linux would do that..... oh well....
Bob
------------------------------
From: "stan168" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.x
Subject: Shutdown Problem
Date: Fri, 27 Aug 1999 15:15:31 +0800
Hi,
Sorry, if you confuse with the subject above. Linux don't have shutdown
problem. I was thinking if the user just want to turn off the power without
doing a shutdown properly. Is there any way to prevent the checking (fsck)
at booting time and data corruption? Should I use the Embbeded Linux, I
wonder how the Embbeded Linux handle this case.
Any help will be appreciate, thanks.
------------------------------
From: [EMAIL PROTECTED] (Dr. Peer Griebel)
Subject: Re: CDROM: Illegal Request
Date: Wed, 01 Sep 1999 12:30:45 GMT
Thanks!
I think the problem was a defective CDROM drive.
------------------------------
** 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
******************************
