Linux-Development-Sys Digest #156, Volume #7 Sun, 5 Sep 99 15:14:29 EDT
Contents:
Re: Can I install Linux on an IBM PS/2 model 95 XP 486? (Torsten Poulin)
Re: Figure Out The MS Source Code Yourself (News system)
Re: The conceptual sandbox? (Kaz Kylheku)
Re: TAO: the ultimate OS (Kaz Kylheku)
Re: Linux standards compliance (Tristan Wibberley)
where to find shared libraries HOWTO (Christoph =?iso-8859-1?Q?Sch=F6nfeld?=)
Re: Video Camera on Linux... (Viljo Hakala)
Re: Shutdown Problem (Randall Parker)
Re: Shutdown Problem (Randall Parker)
Re: Can I compile the kernel using a cc other than gcc? (Randall Parker)
Re: Shutdown Problem (Randall Parker)
Re: TAO: the ultimate OS (void)
fsync/fdatasync performance problems (Martin Schenk)
Re: PROPOSAL: A secure, simple NIS replacement (Darren Spiteri)
Re: mbr boot? (Brian Savacool)
Re: Security, or Lack Thereof... (FS)
mbr boot? (zackary)
----------------------------------------------------------------------------
From: Torsten Poulin <[EMAIL PROTECTED]>
Subject: Re: Can I install Linux on an IBM PS/2 model 95 XP 486?
Date: Sun, 5 Sep 1999 00:19:36 +0200
Peter Samuelson <[EMAIL PROTECTED]> wrote:
> Specifically, what controller is it? I know IBM has used a lot of NCR
> SCSI chips (53C7* and 53C8*) in the past. Perhaps this is because IBM
> signed a deal with NCR many years ago allowing IBM to use NCR's SCSI
> technology. (NCR, in exchange, got to use IBM's Micro Channel
> technology. Someone got shorted.) Linux supports most NCR SCSI chips.
Or go to http://www.dgmicro.com/mca/ and grab a kernel, copy it onto
a Red Hat 5.2 bootdisk and proceed with the installation as normal.
When the installation is done, boot the machine from floppy with
the same kernel, patch the kernel source with the patches from the
same place, rebuild and Bob's your uncle. It worked amiably well
for me when I installed Red Hat 5.1 on a Model 95 XP 486 (an 8595)
last year. The machine has an IBM SCSI adapter (the patches support
at least five different models) and a 3c529 Etherlink III NIC which
both work with the patched 2.0.35 kernel; I also have a Future Domain
adapter (with the text "manufactured exclusively for IBM corp.") and
an Adaptec AHA-1640, but I haven't tried them.
Isn't the NCR 53C7* ISA chips, btw?
-Torsten
------------------------------
From: [EMAIL PROTECTED] (News system)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Figure Out The MS Source Code Yourself
Date: 5 Sep 1999 13:29:01 +0100
Reply-To: [EMAIL PROTECTED]
The question of software licenses is potentially in doubt...if you've
not done so, read:
ftp://koobera.math.uic.edu/www/softwarelaw.html
for more information.
Chris...
Tim Roberts <[EMAIL PROTECTED]> wrote:
>
>The problem with reverse engineering something like Windows is two-fold. First,
>it is illegal; the Windows license agreement prohibits it. Second, Windows is
>just too big. Windows 2000 consists of something like 20 million lines of
>source code.
>
>--
>- Tim Roberts, [EMAIL PROTECTED]
> Providenza & Boekelheide, Inc.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: The conceptual sandbox?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 05 Sep 1999 15:09:10 GMT
On 4 Sep 1999 02:41:59 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>In comp.os.misc James Andrews <[EMAIL PROTECTED]> wrote:
>
>: Hmm, I dont think you can change the definition of a virus, that seems a
>: little absurd.
>
>respectfully, you guys just are not getting it. there are two
>very distinct definitions:
>
>1. a virus is something that when run, corrupts the OS.
You mean like a sound card device driver from 4Front technologies? ;)
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Sun, 05 Sep 1999 15:09:51 GMT
On 4 Sep 1999 02:04:41 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>In comp.os.misc EdToy <[EMAIL PROTECTED]> wrote:
>
>: Sounds like your agenda. So pay 'em then.
>
>the agenda is open.. the agenda is to create a new OS.
>is linux Torvald's agenda? do you ask him to pay
>contributors?
It's Linus Torvalds, not Linux Torvalds.
* plonk *
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Linux standards compliance
Date: Mon, 06 Sep 1999 08:04:04 +0100
Reply-To: [EMAIL PROTECTED]
Leslie Mikesell wrote:
>
> In article <[EMAIL PROTECTED]>,
> Tristan Wibberley <[EMAIL PROTECTED]> wrote:
>
> >- which is probably a good thing because hardware drivers usually need
> >to be GPL or at least Open Source in order to be maintained well and
> >Linux encourages that - UDI drivers will not need that at all and people
> >will end up being forced to insert binary only modules that are poorly
> >written and tend to crash a system.
>
> If you are going to make a claim like that, please include some
> examples of devices where the professionals hired by the equipment
> vendors were unable to supply working drivers for the versions
> that are normally shipped as binaries (Windows, Netware, commercial
> unix, etc.) and volunteers ended up doing a better job.
Many videocard drivers and soundcard drivers often fail to work on 486's
because they use pentium specific opcodes - if you can at least compile
from source yourself you can make sure that doesn't happen (dumb I know,
but there are some).
There are also a great deal of plain buggy drivers which I have had the
misfortune to have to try to use - the vendors then refused to further
support the driver because the hardware was out of date. I'm afraid I
haven't kept records of these cases so I can't prove it for you - but I
bet there are more people reading this newsgroup who have seen the same
thing.
Besides, I am not asking that all hardware drivers are written by
volunteers - I am simply warning that hardware drivers which are only
provided as binaries provide a user with no alternative but to use them
- even if they are buggy. Well, they have the alternative of dumping
their hardware in the bin and buying some more.
I am not suggesting that for pay developers are any worse at writing
software than volunteers - I am suggesting that binary only drivers
cause support (and therefore probably future stability) problems.
The idea that my statement requires that professionals working for money
can't write software as well as volunteers is silly. It doesn't require
that at all - it's about mis-management of intellectual property.
--
Tristan Wibberley
------------------------------
From: Christoph =?iso-8859-1?Q?Sch=F6nfeld?=
Subject: where to find shared libraries HOWTO
Date: Sun, 05 Sep 1999 17:47:32 +0000
Hi,
could someone point me to a shared lib HOWTO or something (not man
dlopen)?
thanks
Christoph
PS: please mail me too if you answer to the newsgroup
------------------------------
From: [EMAIL PROTECTED] (Viljo Hakala)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: Video Camera on Linux...
Date: 5 Sep 1999 15:28:50 GMT
On Sun, 05 Sep 1999 00:53:01 -0600, William Epperson Jr. <[EMAIL PROTECTED]>
wrote:
>
>--------------39060BE8418D6A10154C73A1
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Currently the Linux kernal does not support the USB interface. Correct
>me if I am wrong on the next point, but I don't think the latest Kernal
>2.2.* does either. Parrallel cam would be your only recourse. Hooking
>it up however is unknown to me as well.
The USB support is in development. The first drafts appeared in 2.2.7,
and the most active development is done in the 2.3 kernel serie.
There's a driver for CPiA based USB video cameras, many vendors use it today,
such as Creative. Both the USB and CPiA support are in their early stages,
cpia cameras are known to work, but not very well (random crashes).
The latests 2.3-kernels may have the fixed versions, and thus removing
the reported crashes, you can only
see it for yourself by testing it or asking others' opinion.
Visit http://www.linux-usb.org/ for more information.
--
Viljo Hakala <[EMAIL PROTECTED]>
Public PGP-key at http://www.pcuf.fi/~vipe/pgpkey.asc
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.x
Subject: Re: Shutdown Problem
Date: Sat, 4 Sep 1999 13:24:25 -0700
Peter,
Aren't there temp files that need a place to be written? What if you have
only a local machine no remote mount you can write them to?
I think Linux should have an easier way to be configured so that the
updatable files do not share partitions with system files that are only
written at install and patch times.
Also, temporary scratch pad and log files should be easily configured to
go to a different partition than the one that holds configuration files.
Granted the configuration files get written to any time you add, say,
dialer entries or logical to numeric socket definitions (HOSTS file on
most OSs). But these files are not updated very often and should be on a
partition that usually has no uncommitted metadata changes. That way a
power failure would be far less likely to cause their loss as part of a
whole partition's metadata becoming corrupted.
In article <7q6tl3$eou$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> [stan168 <[EMAIL PROTECTED]>]
> > 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?
>
> Mount all your local filesystems read-only.
>
>
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.x
Subject: Re: Shutdown Problem
Date: Sat, 4 Sep 1999 13:24:26 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> On Fri, 27 Aug 1999 17:03:33 -0400, Alan Swartz <[EMAIL PROTECTED]> wrote:
> >stan168 wrote:
>
> >> 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?
> >
> >I'm curious: Why would you want to do that?
>
> One reason is to protect against power failures.
Exactly. Or some other hardware or software problem that causes a crash.
Not all crashes can be foreseen in advance.
>
> If we have /usr /usr/bin /sbin and the other read-only stuff on one partition,
> then we can mount this partition read-only and in the event of a power
> failure won't mess up these partitions. To be honest, I haven't yet tried
> this idea. But I think it is a good idea.
I keep saying that the installs ought to treat certain types of
directories and files as groups whose locations can be aimed at
particular partitions _as groups_.
ie be able to say "Put all configuration files on partition xyz" and not
have to know what are all the file names that are being moved there.
>
> On my system, I have /tmp in its own partition, /var in its own, /home in
> its own, / in its own, /usr in its own. So maybe I should give it a shot.
I may be mistaken: Aren't there parts of Linux that write temporary files
in places other than /tmp?
>
> --
> Siemel Naran
>
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.portable
Subject: Re: Can I compile the kernel using a cc other than gcc?
Date: Sat, 4 Sep 1999 13:24:23 -0700
In article <7pqvso$k6r$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Hmmmm, how many of those extensions are used in arch-independent code,
> I wonder? And I know some GNU extensions (__attribute__ comes to mind)
> were designed to be easy to dispose of in the preprocessor if needed.
> Some (like typeof) obviously are not.
IMO, the kernel should be gradually migrated to eliminate non-portable
extensions.
> Wasn't Metrowerks at least somewhat interested in implementing enough
> GNU extensions so that the kernel could take advantage of their (said
> to be superior) CodeWarrior PowerPC compiler?
The DEC C compiler is way faster on Alpha. So if Compaq/DEC/et al could
get Linux ported to that compiler then Alpha Linux could be much faster.
The reports of Mandrake users seeing much snappier performance with
basically a more optimized version of Red Hat demonstrate, IMO, that
compiler optimization really can help quite a lot.
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.x
Subject: Re: Shutdown Problem
Date: Sat, 4 Sep 1999 13:24:24 -0700
Alan,
People don't want to have data corruption. If you eliminate the need to
do fsck you must have, by definition, eliminated the types of corruption
that make fsck necessary in the first place. The main goal here isn't to
avoid the time needed to run fsck. The goal is to eliminate situations
where, for instance, the OS partition has to be restored from tape
IMO, the distribution installs ought to provide the option to tell them
to put the OS on a partition that will be read-only (except when being
updated), all the temp files on a different partition, and all the config
files (dialer files, hosts, etc) on yet another partition.
If the OS directory has no uncommitted metadata at the time of a system
crash or power failure (my cleaning lady has inadvertently circumvented
my UPS protection twice in the last 3 years btw) then it can't become
corrupted.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> stan168 wrote:
>
> > 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?
>
> I'm curious: Why would you want to do that?
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 5 Sep 1999 16:33:36 GMT
On Sat, 4 Sep 1999 18:13:28 -0500, EdToy <[EMAIL PROTECTED]> wrote:
>In article <7qpunp$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>>
>> the agenda is open.. the agenda is to create a new OS.
>> is linux Torvald's agenda? do you ask him to pay
>> contributors?
>
>Well he certainly didn't do any favors to the ones who gave up their time
>so that Red Hat could make all that money that's for sure. It's the same
>scam that built the pyramids of Egypt.
Linus doesn't receive money from Red Hat either.
He was working for free on Linux long before anyone made a cent off of
it. I'm no Linus-worshipper, but accusing him of greed and exploitation
is blatant revisionism.
--
Ben
[X] YES! I'm a brain-damaged lemur on crack, and I'd like to
order your software package for $459.95!
------------------------------
From: Martin Schenk <[EMAIL PROTECTED]>
Subject: fsync/fdatasync performance problems
Date: Fri, 03 Sep 1999 22:43:31 +0200
This is a multi-part message in MIME format.
==============70F991BA96EE45541CD99842
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
fsync/fdatasync (it seems there is no difference
with current kernels) takes a lot of CPU when syncing
a large file.
I observed this problem when testing a program which syncs
every change. When the file gets big, syncs take a lot of time
and the program ends up using almost all CPU ( I originally thought
my program would be limited by harddrive seek time and was very
surprised when I saw it use > 90% CPU ).
Attached is a small program showing the problem.
Starting it with a parameter of 1000 (=2Mb) the second phase (which
always does
1000 writes) takes about 12 seconds, with 5000 (=10Mb) 20 seconds, with
50000
(=100Mb) 500 seconds (!!!).
Should I use another call to synchronise my changes ?
PS: I tested this with 2.0.36 and 2.2.10
--
Martin Schenk <[EMAIL PROTECTED]>
Richard-Wagnergasse 46, A-8010 Graz, Austria
==============70F991BA96EE45541CD99842
Content-Type: text/plain; charset=us-ascii; name="synctest.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="synctest.c"
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
int main(int argc, char **argv)
{
int fd,i;
char buff[2048];
int size;
size=atoi(argv[1]);
if (size<1000) exit(1);
fd=open("tst", O_RDWR | O_CREAT | O_TRUNC, 0666);
if (fd<0) exit(1);
memset(buff, 0, 2048);
printf("init \n");
for (i=0; i<size; i++)
{
write(fd, buff, 2048);
}
fdatasync(fd);
printf("sync\n");
lseek(fd, 0, SEEK_SET);
for (i=0; i<1000; i++)
{
write(fd, buff, 2048);
fdatasync(fd);
}
close(fd);
}
==============70F991BA96EE45541CD99842==
------------------------------
From: [EMAIL PROTECTED] (Darren Spiteri)
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: Sun, 5 Sep 1999 18:28:30 +1000
In comp.security.unix [EMAIL PROTECTED] wrote:
> [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.
> 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.
You can do this with rsync over SSH, it's secure and reliable.
--
+-\___ ___ ______ __ __/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\-+
: / __)| _ \||_ _| /__/_/ NOTE: Above email address is fictitious. :
|:__ \: _:: :: : @# '') "Bunch of savages in this town..." - Dante |
`(____/|_|><|_||_|><><\__3- - -*(at)hempseed(dot)com><><><><><><><><><>'
------------------------------
From: Brian Savacool <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup,redhat.config
Subject: Re: mbr boot?
Date: Sun, 05 Sep 1999 14:38:04 +0000
What you can do i go back into linuxconf
and setit to boot from the mbr
then here is what you probly forgot
after you do that, and save the changes
type lilo @ the uper user prompt (#)
# lilo
that activates the changes and writes to lilo
(don't for get to make the changes to the Win98
options, ie, make sure u can boot it with lilo)
Hope it works
[EMAIL PROTECTED]
zackary wrote:
> hello guys,
> I have a dual boot system in my pc. One is win98 and another is linux
> (redhat 6.0). My pc boot used to boot to dos insted of linux but under
> linux control. I mean I install lilo ( i guess..) in MBR then from
> 'linuxconf' I set it to boot to dos instead of linux. and it run fine
> until one day my win98 force me to install it again on my hard disk. So I
> install it again. The problem is win98 take over the MBR ( i guess ..
> again. Correct me if i was wrong!) and at the boot up there is no more
> 'boot: ' prompt, it direct to win98. So i have to use my linux boot disk
> every time to boot linux.
> So how could i get linux on the MBR back as previous order. Or in other
> words to get the 'boot: ' prompt back.
>
> Thank you
> -azaria-
>
> ------------------ Posted via CNET Linux Help ------------------
> http://www.searchlinux.com
------------------------------
From: FS <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Security, or Lack Thereof...
Date: Sun, 05 Sep 1999 18:49:04 GMT
There is a big security issue. If you install the system the maximum standard
or the minimum standard, there are peices open to the public that are a
security risk.
"Christopher B. Browne" wrote:
> On 4 Sep 1999 02:27:30 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]>
> posted:
> >In comp.os.misc Theodore Y. Ts'o <[EMAIL PROTECTED]> wrote:
> >
> >: 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.
> >
> >imho more false dichotomies. there is a consistent belief by
> >programmers that you can't win when dealing with novice users.
> >programmers, remarkably, many of whom have worked on open
> >source projects, have some of the most elitist attitudes
> >on the planet.
>
> False dichotomy? Or are you merely in a state of denial that the
> problems researchers have found to be problems actually are problems?
>
> >: 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.
> >
> >bzzzzt totally (respectfully) disagree on this. I believe
> >a robust security system is possible with a different
> >granularity other than those that currently exist. it is
> >not so much file-oriented anymore but object oriented.
> >it keeps track of what objects (apps) own other objects.
> >
> >this is a parallel security system that works in tandem
> >with the security related to individual users. in fact
> >each user in a sense has their own sandbox, and each
> >application has its own sandbox, and their are
> >sandboxes within applications, etc.
>
> We already know where this takes people; this sort of security scheme
> has been in place in mainframe environments for many years now, with
> Top Secret and the likes.
>
> These sorts of environments require an army of security administrators
> to set up the capabilities appropriately, and to fix things when they
> break, which inevitably does happen.
>
> >: The other approach which has been tried is code signing --- but that
> >: assumes that the code signers are trustworthy.
> >
> >I think code signing is part of the solution but has
> >been implemented poorly. I think it is appropriate that
> >some utilities are signed, such as system level ones,
> >but one should also permit "anonymous" applications
> >that can run without harm, but may be limited in
> >function (e.g. not allowed to format hard drive)
>
> Dennis Ritchie's award winning paper entitled "Reflections on Trusting
> Trust" debunks this; it establishes a "trojan horse" methodology that
> cannot be avoided, and where the evidence goes back to roughly the
> late '60s or early '70s.
>
> >: 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.
> >
> >I don't understand what you are talking about. what is a "read-only
> >compromise of sensitive data"? I think you are talking about
> >an entirely different kind of security, i.e. that you don't
> >want to divulge certain kinds of information.. but in fact
> >this is a ridiculous requirement of an open OS system.. or
> >at least it is a much higher standard than anything that
> >we are interested in, that few entities other than defense
> >contractors and the NSA are seriously interested in right now..
>
> Does that mean that we can peg you as a clear disadvocate of
> maintenance of privacy?
>
> - If I write a spreadsheet, *I* must control whether it is released
> from my PC to someone else's, or not.
>
> - If I enter personal accounting information on my system, I don't want
> that data published in public.
>
> - If I type in credit card information into notes on my system, I don't
> want any processes grabbing that data and emailing it out to
> email.frauds.r.us.org.
>
> If you consider that protecting the privacy of information is only of
> importance to defence contractors or the NSA, that certainly shows where
> your priorities are...
>
> >: 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.
> >
> >I absolutely disagree (respectively) that there is no elegant way
> >to handle all these issues. I do agree that it has been poorly
> >handled to date, and judging by existing systems, it is
> >an impossible problem. I'm saying the sandbox concept is the
> >place to start. I'm saying I want to hash out the details with
> >people who agree it is possible. for those who do, please
> >sign up for the mailing list (details below).
>
> Those with infinite faith in the notion of sandboxes to solve All
> Possible Security Problems should certainly join you.
>
> It should certainly be taken offline, as it doesn't belong in
> alt.os.linux, comp.os.linux.advocacy, comp.os.linux.development.system,
> or comp.os.misc,comp.unix.advocacy.
>
> >: Not specifying such troubling, niggling little details is part of the
> >: hand-waving and arm-waving which is going on here.
> >
> >there are lots of difficult details. its hand waving and
> >arm waving. I'm saying its POSSIBLE. for those who agree with
> >me, I am confident we can work out the details. "let's do it"
>
> Hand waving isn't good enough. Proving the security of systems is as
> much a task of mathematical analysis as it is anything else. That is
> precisely the implication of the A1 level defined by TPEP.
>
> Given a clear set of definitions (which are lacking here) it is possible
> to then establish a set of starting states (which are lacking here),
> transformations (again, lacking), and "security faults," (lacking)
> and then analyze the system to see what transformations do and do not
> result in security faults.
>
> See virtually any of the papers by Bruce Schneier of Counterpane Systems
> or his well-received book for a systematic set of examples and analyses.
>
> It's POSSIBLE that monkeys will fly out of my butt; that is probably about
> as likely an outcome as your confidence resulting in a secure system.
> --
> cc hello.c, in Canada, results in:
> eh.oot
> [EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/crypto.html>
------------------------------
From: zackary <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup,redhat.config
Subject: mbr boot?
Date: Sun, 05 Sep 1999 17:31:08 GMT
hello guys,
I have a dual boot system in my pc. One is win98 and another is linux
(redhat 6.0). My pc boot used to boot to dos insted of linux but under
linux control. I mean I install lilo ( i guess..) in MBR then from
'linuxconf' I set it to boot to dos instead of linux. and it run fine
until one day my win98 force me to install it again on my hard disk. So I
install it again. The problem is win98 take over the MBR ( i guess ..
again. Correct me if i was wrong!) and at the boot up there is no more
'boot: ' prompt, it direct to win98. So i have to use my linux boot disk
every time to boot linux.
So how could i get linux on the MBR back as previous order. Or in other
words to get the 'boot: ' prompt back.
Thank you
-azaria-
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
** 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
******************************
